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, plus selector-gated durable ledgers exercised by CI. Merged and exercised by CI, but not production-active: committed Human-Plane migrations, a provider-neutral PostgreSQL isolation substrate with adversarial cross-tenant proofs, a provider-neutral identity boundary with an opaque user identifier and verified-email invitation authority, and a per-request corridor that runs the converted routes' storage calls inside one transaction carrying the tenant principal. That corridor IS on the live request path — and carrying the principal is not enforcing a policy: no shipped code applies the migration or switches the application to a non-owner role, so the row-level-security policies are not in force. Nothing is on an open implementation branch right now. Roadmap: hosted multi-tenant operation, managed key custody, and billing. The discipline of not blurring those three states is part of the thesis: the product's entire value is trustworthy evidence, so a company selling verifiable proof cannot afford a single overclaim. 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.

Why now?

Agents are moving from generating content to taking real actions against codebases, infrastructure, payments, customer records, and operational systems. An organization cannot safely scale agent authority without being able to establish who or what had authority, what was attempted, what was refused, what actually reached the downstream system, and whether the record was later modified. That gap is what this addresses.

What is the commercial thesis?

The trust mechanics are designed to be independently checkable, because independence is the whole value. The commercial value sits in managed organizational control: tenancy, policy administration, evidence operations, enterprise integration, and hosted services. That is what the multi-tenant build turns the proof system into — subject to the current private-access distribution and IP posture.

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 you run yourself — not broad production SaaS, and not a hosted multi-tenant service.
  • Enforcement is scoped to the MCP tools/call method class. Other MCP methods pass through the gateway ungated; we state that rather than implying every agent action is governed.
  • Multi-tenancy: organization scoping exists in the Human Plane at the application layer, behind a hosting-environment gate. The database-enforced tenant boundary and the per-request corridor that carries the tenant principal are merged and exercised by CI, and are not production-active by this project: no shipped code puts the row-level-security policies in force.
  • The durable evidence ledger is self-host and selector-gated; it is not activated in the default deployment, so the hosted evidence surface is ephemeral.
  • 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 pins two separate anchors: the witness key and the ceremony-sourced receipt-issuer key. Pinning the witness key alone is fail-open on receipt provenance. The security model documents the 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