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?

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.

What stops agent overreach — an agent widening its own authority?

Capabilities are delegated by the operator and carried outside the agent's control; the agent cannot grant itself more. Amount limits are parsed exactly and enforced at the gate, so 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?

The evidence bundle is independently verifiable: a standalone verifier re-derives the chain, the signatures, and the Merkle root. Flip one byte and verification fails with an explicit divergence error.

Do I have to trust your code to trust the evidence?

No. The verifier is deliberately separate — it imports nothing from the server. Independent verification is the design goal; the remaining trust assumptions (key custody, witness posture) are documented in the security model rather than waved away.

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 — 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.

Request a private evaluation