Magenta Canon is an MCP gateway your agents call through. It enforces operator-delegated capability ceilings at runtime — default-deny, exact-amount parsing, blocked calls never reach the tool — and emits signed receipts your team can verify with a standalone verifier, from source, without trusting our code.

  • 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 VP ENGINEERING / CTO

You are responsible for shipping agent capability fast — without an agent-caused incident landing on your desk.

Magenta Canon is an MCP gateway your agents call through. It enforces operator-delegated capability ceilings at runtime — default-deny, exact-amount parsing, blocked calls never reach the tool — and emits signed receipts your team can verify with a standalone verifier, from source, without trusting our code.

Request a private evaluation Read the proof

Your top questions, answered

How does it integrate with what we have?

It sits between the agent and its tools as an MCP gateway: the agent's tool calls route through the gate, which forwards allowed calls downstream and refuses the rest. Your downstream tools need no modification — their own logs become part of the proof.

What exactly is enforced at runtime?

A small, strict capability grammar — for example a refund capability with a hard ceiling in cents — evaluated default-deny with exact integer parsing. Unknown actions, unknown tools, and over-ceiling amounts are refused at the gate.

Can my team verify the claims instead of taking them on faith?

Yes — that is the point. Evaluation is repo-source from a granted private checkout: your engineers run the demo, read the gateway and verifier source, and re-derive the cryptography with a verifier that imports nothing from the server.

What is real today vs roadmap?

Real today: the full gate → witness → receipt → verify loop, runnable end to end, with tamper detection. Roadmap, labeled as roadmap: durable hosted receipts, hosted multi-tenant operation, and managed key custody.

What does it cost us in complexity?

One gateway process in the tool-call path and one verifier script outside it. The reference implementation is single-tenant and self-run, so you evaluate it in your own environment on your own terms.

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 proof path (delegate to one engineer, roughly 15 minutes):

  1. From a granted private checkout, run the demo proof loop and confirm the allow, the block, and the downstream absence.
  2. Run the standalone verifier on the emitted bundle (VERIFIED) and on the tampered bundle (FAILED).
  3. Read scripts/mcp-gateway.ts and scripts/magenta-verify.ts — the gate-first invariant and the verifier's independence are in the source.

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