Magenta Canon produces a signed, hash-chained record of every AI-agent action decision — what was allowed, what was blocked, and under what delegated authority — that can be verified by an independent party without trusting or running the vendor's server. It is an evidence layer: interpretation and compliance determination remain with you.
- 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 LEGAL / COMPLIANCE
You are responsible for whether AI-assisted actions are defensible — before a regulator, a court, or your own audit.
Magenta Canon produces a signed, hash-chained record of every AI-agent action decision — what was allowed, what was blocked, and under what delegated authority — that can be verified by an independent party without trusting or running the vendor's server. It is an evidence layer: interpretation and compliance determination remain with you.
Your top questions, answered
What record exists after an agent acts?
A signed receipt for every decision — allows and blocks alike — hash-chained on a Merkle transparency log with a signed tree head. The record shows the action, the delegated authority it was evaluated against, and the outcome.
Can the record be checked by someone who doesn't trust the vendor?
Yes. The standalone verifier shares no code with the server and re-derives the signatures, the chain, and the Merkle root from the evidence bundle alone. An altered record fails verification explicitly.
Does this certify compliance?
No, and we say so plainly: no SOC 2, HIPAA, or similar certification is claimed. Magenta Canon produces verifiable evidence of agent-action control; compliance determination and legal judgment remain the responsibility of external reviewers.
What kinds of boundaries can be expressed?
Under a bounded assignment the enforced boundary is the full grant envelope — which agent, which run, which tools, until when, revocable at any time — with hard limits such as refund ceilings and a restricting operator-policy overlay. Outside assignment mode it falls back to flat capability strings with hard limits and no expiry or revocation. A ratified policy-pack library documents common patterns — draft-but-don't-send, read-only access, escalate-but-don't-decide — as reference fixtures validated by tests rather than gateway-loaded rules.
If we operate multiple entities, are their records separated?
Organization scoping exists today in the administrative plane, enforced at the application layer behind a hosting-environment gate. A database-enforced isolation boundary is merged and CI-exercised, and the per-request corridor that carries the tenant principal is merged with it, but neither is production-active: no shipped code puts the policies in force. We will not tell you it is in place before it is. The evidence records themselves are per-deployment: the trust core is one evidence universe, not a tenant-partitioned store.
What happens to blocked actions?
They are refused before reaching the downstream system and recorded as blocked. The downstream system's own log corroborates the absence — useful when you need to show a prohibited action did not occur.
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 review path:
- Read the proof story: allowed, blocked, absent downstream, verified, tamper-fails.
- Ask your technical counterpart to run the verifier on the sample evidence — including the tampered negative control.
- Review the honest-scope statement and docs/SECURITY_MODEL.md for what is and is not claimed.
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