Magenta Canon's evaluation is repo-source from a granted private checkout: you run the seven-step demo yourself, watch an $89 refund get allowed and a $250 refund get blocked at the gate, confirm the downstream log never saw the blocked call, verify the evidence bundle with a standalone verifier — and then verify the tampered bundle and watch it fail.

  • 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 TECHNICAL EVALUATOR

You are responsible for finding out whether this is real. Here is the exact path — copy/paste, from source.

Magenta Canon's evaluation is repo-source from a granted private checkout: you run the seven-step demo yourself, watch an $89 refund get allowed and a $250 refund get blocked at the gate, confirm the downstream log never saw the blocked call, verify the evidence bundle with a standalone verifier — and then verify the tampered bundle and watch it fail.

Request evaluator access Read the proof

Your top questions, answered

What can I actually run today?

The full proof loop, locally, from the repo: a live gateway boot, an allowed call, a blocked call, a downstream ground-truth check, evidence export, independent verification, and a tamper negative-control. Four commands, listed below.

What is real versus demo?

The gate, receipts, transparency log, verifier, and the STH mirror leg are real and run in front of you — including the negative cases: a tampered bundle fails, and a rewritten mirror record fails closed. The demo universe is throwaway — its witness key is minted per run and is not a production key — and the hosted evidence surface is ephemeral unless a durable ledger selector is set.

How do I verify the evidence independently?

scripts/magenta-verify.ts imports only node:crypto, node:fs, and tweetnacl — nothing from the server. Pin BOTH anchors: --expected-witness-key pins who witnessed the log, and --expected-issuer-key pins who signed each receipt. The witness key alone is fail-open on receipt provenance — a bundle with no issuer material and no reveals still reports ORIGIN AND INTEGRITY VERIFIED, and the verifier says so in its [SKIP] lines — so the issuer anchor is what makes that case fail closed. They differ in provenance too: the issuer anchor is ceremony-sourced, while the demo's witness key is read from the bundle, so pinning it locally demonstrates the mechanism rather than proving independent witness origin.

What does the gateway block, exactly?

Anything not matching a delegated capability: unknown actions, unknown tools, and amounts over the ceiling (the demo's grant is a refund ceiling; $250 against a $100 ceiling is refused). Default-deny, evaluated before the call leaves the gate.

What does the downstream tool see?

Only the allowed call. The demo asserts ground truth from the downstream side's own log: exactly one call arrived, and the blocked one is absent.

What would a private evaluation look like?

A granted private checkout, the quickstart below, then a working session against one of your own workflows. Request access and we set it up.

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

The canonical quickstart (docs/EVALUATOR_QUICKSTART.md), from the repo root of a granted checkout:

npm ci
npm run demo -- --keep --output ./out
npx tsx scripts/magenta-verify.ts ./out/evidence-bundle.json --expected-witness-key ./out/witness-key.pub --expected-issuer-key ./out/issuer-key.pub
npx tsx scripts/magenta-verify.ts ./out/tampered-bundle.json --expected-witness-key ./out/witness-key.pub --expected-issuer-key ./out/issuer-key.pub

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 evaluator access