Magenta Canon is the platform's 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.

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?

Yes, and it is enforced rather than aspirational on the path that matters. Under a bounded assignment the stdio gateway runs the whole grant envelope — agent and run binding, activation window, expiry, revocation, an explicit deny-tools list, grant integrity — plus a restricting operator-policy overlay that may only narrow a grant, never widen one. A require-review outcome is refused, not allowed, because no human-approval path is wired. Separately, a library of ratified policy packs ships as reference fixtures validated by tests; no gateway path loads those packs, and we keep that distinction rather than blurring it.

Is it multi-tenant?

Partly, and we are precise about which part. The Human Plane — organizations, members, roles, invitations, projects, agents, resources — exists today with application-layer tenant scoping, behind a hosting-environment gate. A database-enforced tenant boundary (committed migrations plus provider-neutral PostgreSQL row-level security, with adversarial cross-tenant isolation proofs) is merged and CI-exercised, and the per-request corridor carrying the tenant principal is merged with it — but it is NOT production-active: no shipped code puts those policies in force. Hosted multi-tenant operation is roadmap. The trust core is unaffected either way: it remains one evidence universe per deployment.

Which MCP methods are actually governed?

The tools/call method class. That is where an agent asks to act, and that is what the gate evaluates before anything reaches the downstream tool. Other MCP methods — initialize, tools/list, and the rest — are forwarded ungated. We name the scope rather than saying we govern every agent action.

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:

Run the demo proof loop from a granted private checkout and watch the gate allow, refuse, and record.
Inspect the policy-pack library (examples/policy-packs/) and the capability grammar the runtime gate enforces.
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 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