Magenta Canon is a default-deny gateway for AI-agent tool calls. Each call is evaluated against an operator-delegated capability before it executes; allows and blocks alike become Ed25519-signed, hash-chained receipts on a Merkle transparency log; and a standalone verifier that shares no code with the server checks the evidence — including catching tampering.

  • 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 CISO / SECURITY LEADER

You are responsible for what agents are permitted to do — and for proving, afterward, what they actually did.

Magenta Canon is a default-deny gateway for AI-agent tool calls. Each call is evaluated against an operator-delegated capability before it executes; allows and blocks alike become Ed25519-signed, hash-chained receipts on a Merkle transparency log; and a standalone verifier that shares no code with the server checks the evidence — including catching tampering.

Request a private evaluation Read the proof

Your top questions, answered

How does it stop unauthorized actions — including an agent widening its own authority?

The gate is default-deny: an action executes only if it matches a capability the operator explicitly delegated (for example, refunds up to a hard ceiling). Anything else is blocked before it reaches the downstream tool — not flagged after. Capabilities are delegated by the operator and carried outside the agent's control, so the agent cannot grant itself more, and amount limits are parsed exactly at the gate: a $250 request against a $100 ceiling is refused.

What audit trail do I get?

Every decision — allow and block — becomes a signed, hash-chained receipt on a Merkle transparency log, with a signed tree head. Incident reconstruction works from the receipts plus the downstream system's own log, which shows blocked calls never arrived.

How do I know the evidence hasn't been altered — or the history quietly rewritten?

Two separate checks. First, the evidence bundle is independently verifiable: a standalone verifier that imports nothing from the server re-derives the chain, the signatures, and the Merkle root, and flipping one byte fails with an explicit divergence error — pin both anchors, because the witness key alone is fail-open on receipt provenance and only the ceremony-sourced issuer anchor closes that. Second, an append-only, hash-chained STH mirror kept outside the Magenta runtime catches what a bundle check cannot — once a signed tree head is mirrored, a rewritten history, an equivocation (two different roots at the same tree size), a rollback, or an edit to the mirror file itself is detected and fails closed. Be clear-eyed about that second one: it is a property of custody, not of our code. Hold the mirror somewhere we do not control, or it establishes nothing, and it says nothing about history before the first mirrored tree head. A hosted, independently operated mirror service is not built.

How is one team's data separated from another's?

Today the Human Plane — organizations, members, roles, invitations, projects, agents, resources — scopes tenants at the application layer, behind a hosting-environment gate. The database-enforced backstop is built and merged: committed migrations plus provider-neutral PostgreSQL row-level security keyed on a transaction-local verified principal, so that once the policies are in force a missed application predicate returns zero rows instead of leaking. The per-request corridor that carries that principal is merged too. What is NOT done is putting the policies in force — no shipped code applies the migration or switches the application to a non-owner role, so it is not production-active by this project. The trust core is separate and is one evidence universe per deployment.

Which agent actions are actually governed?

The MCP tools/call method class — where an agent asks to act. Other MCP methods are forwarded ungated. We name the enforced scope rather than claiming every agent action is governed, because you would find out either way.

What does it NOT do?

It does not solve model alignment, and it does not certify compliance. It gates external tool calls, records decisions, and makes the evidence independently verifiable — a control-and-evidence layer, not a silver bullet.

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. Review the Trust & Security page (/trust): security contact, non-claims, and the verification path.
  2. Have your team run the demo and both verifier verdicts (VERIFIED and tamper-FAILED) from a granted private checkout.
  3. Review docs/SECURITY_MODEL.md for the explicit trust assumptions and key-custody posture.

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.

Request a private evaluation