As AI agents get authority over real systems, someone has to govern what they may do and prove what they did. Magenta Canon's wedge is that both halves are cryptographic and independently checkable: a default-deny gate in the tool-call path, and evidence that verifies — or fails on tampering — without trusting the company that produced it.

  • Gate-first: authorized actions are allowed and over-authority actions are blocked before they reach the tool
  • Recorded: every allow and block becomes a signed, hash-chained receipt on a Merkle transparency log
  • Verifiable: a standalone verifier re-derives the cryptography and shares no code with the server

FOR INVESTOR / PARTNER

You are responsible for judging whether this is a real wedge — and whether the team's claims survive contact with the evidence.

As AI agents get authority over real systems, someone has to govern what they may do and prove what they did. Magenta Canon's wedge is that both halves are cryptographic and independently checkable: a default-deny gate in the tool-call path, and evidence that verifies — or fails on tampering — without trusting the company that produced it.

Start the conversation Read the proof

Your top questions, answered

What is the wedge?

The gate-to-evidence loop: agent actions are allowed or blocked against delegated authority before execution, and every decision becomes signed, verifiable evidence. Control plus proof, in one runnable path.

What is actually proven versus pitched?

Proven and runnable today: the full gate → witness → receipt → verify loop with tamper detection, from source. Roadmap, labeled as such: durable hosted receipts, tenancy, and billing. The discipline of not blurring that line is part of the thesis.

Why is under-claiming strategic rather than timid?

The product's entire value is trustworthy evidence. A company selling verifiable proof cannot afford a single overclaim — so honest scope is enforced in the copy, the docs, and the tests, and the proof is designed to be checked by people who do not trust us.

How do I diligence this in one sitting?

Read the proof page, then have any engineer you trust run the demo and both verifier verdicts from a granted checkout. The core claims resolve to exit codes, not adjectives.

What is the current go-to-market posture?

Private-access proof system: controlled design-partner evaluations from a granted private checkout. No public package distribution — deliberately — while the core IP and licensing posture are protected.

The proof story

The same demo runs every time — five beats, each independently checkable.

  • Allowed

    An $89 refund, within the delegated ceiling, is forwarded to the downstream tool.

  • Blocked

    A $250 refund exceeds the ceiling and is blocked at the gate — before it reaches the tool.

  • Absent downstream

    The downstream tool's own log shows the blocked call never arrived.

  • Verified

    A standalone verifier — sharing no code with the server — returns ORIGIN AND INTEGRITY VERIFIED.

  • Tamper fails

    Flip one byte of the evidence and verification fails. Tampering is caught, not hidden.

Your proof path

Your diligence path:

  1. Read /proof — the committed, independently verifiable evidence walkthrough.
  2. Have a technical contact run the demo and the tamper negative-control from a granted checkout.
  3. Talk to us about the roadmap: durability of the trust core first, then tenancy, then commercial surface.

Honest scope — what this is, and is not, today

Under-claiming is the brand. Here is the current posture, stated plainly:

  • Evaluation today is private-access and repo-source: a granted private checkout. There is no public npm/npx install path.
  • What runs today is a reference proof path — a single-tenant reference implementation you run yourself. This is not broad production SaaS.
  • The durable hosted witness is not activated in production; the hosted evidence surface is ephemeral unless it is.
  • No compliance certification is claimed — no SOC 2, HIPAA, or similar. Compliance determination and legal judgment remain with external reviewers.
  • Verification is server-independent — the standalone verifier shares no code with the server — and the security model documents its remaining trust assumptions (docs/SECURITY_MODEL.md).

Ready to look closer?

Evaluation is private and design-partner controlled — a granted checkout and a direct line to us.

Start the conversation