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.

Request a private evaluation Read the proof

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?

The enforced runtime boundary is delegated capability with hard limits (for example, refund ceilings). A ratified policy-pack library documents common patterns — draft-but-don't-send, read-only access, escalate-but-don't-decide — as design artifacts validated by tests.

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:

  1. Read the proof story: allowed, blocked, absent downstream, verified, tamper-fails.
  2. Ask your technical counterpart to run the verifier on the sample evidence — including the tampered negative control.
  3. 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 — 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