Magenta Canon gives the platform a choke point: agents call tools through an MCP gateway that enforces operator-delegated capabilities per action, refuses everything not delegated, and turns every decision into a signed receipt on a transparency log — so 'what can this agent do?' has an enforced answer and 'what did it do?' has a verifiable one.

  • 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 AI PLATFORM LEAD

You are responsible for the platform every team's agents run on — and for the blast radius when one of them overreaches.

Magenta Canon gives the platform a choke point: agents call tools through an MCP gateway that enforces operator-delegated capabilities per action, refuses everything not delegated, and turns every decision into a signed receipt on a transparency log — so 'what can this agent do?' has an enforced answer and 'what did it do?' has a verifiable one.

Request a private evaluation Read the proof

Your top questions, answered

How do I stop one team's agent from exceeding its scope?

Capabilities are delegated per action with hard limits (for example, refunds up to a ceiling; tool calls only to named tools). The gate is default-deny, so scope is what you delegated — not what the agent decided to try.

Does it fit an MCP-based stack?

Yes — it IS an MCP gateway. Agents that speak MCP route through it; allowed calls are forwarded to the downstream tool, refused calls never leave the gate.

What evidence exists per decision?

Each allow and each block becomes an Ed25519-signed, hash-chained receipt on a Merkle log with a signed tree head. Evidence bundles export cleanly and verify with a standalone verifier.

Is there a policy story beyond raw capabilities?

A library of ratified policy packs exists for common boundaries — refund ceilings, read-only database access, draft-but-don't-send email, staging-only deploys, and more. Today these are design artifacts validated by tests; the runtime gate enforces the capability grammar. We keep that distinction honest rather than blurring it.

Is it multi-tenant?

Not today. It is a single-tenant reference implementation you run yourself; tenancy is roadmap and is labeled as roadmap.

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:

  1. Run the demo proof loop from a granted private checkout and watch the gate allow, refuse, and record.
  2. Inspect the policy-pack library (examples/policy-packs/) and the capability grammar the runtime gate enforces.
  3. Verify the emitted evidence bundle independently, then the tampered bundle to see verification fail.

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