The Magenta platform is a verifiable MCP accountability gateway organized in three separable planes. The Trust Plane — gate, authority, receipts, witness, verification, tamper evidence — is proven today and is what the runnable proof demonstrates. The Human Plane is where organizations, members, projects, and agents are administered; its application-layer tenant scoping is supported and environment-gated; the database-enforced isolation boundary and the per-request corridor that carries the tenant principal are merged and CI-exercised, and are still not production-active because no shipped code puts the row-level-security policies in force. The Commercial Plane — subscription, entitlements, billing — is not built. Magenta is a reference implementation under private design-partner evaluation, not a hosted production SaaS, and it claims no compliance certification.

  • Trust Plane, proven today: default-deny gating of the MCP tools/call method class before downstream execution, signed hash-chained receipts, and an independent verifier
  • Human Plane, supported and environment-gated today: organization scoping at the application layer; the database-enforced tenant boundary is under development and is not activated anywhere
  • Commercial Plane, not built: billing would gate commercial access and would never grant execution authority

MAGENTA PLATFORM

The control plane for verifiable AI-agent actions

Magenta sits at the tool boundary. It allows delegated actions, blocks withheld actions before downstream execution, records both, and produces evidence a reviewer can verify independently.

Where Magenta Sits

An agent or MCP host asks to call a tool. The Magenta gateway intercepts that tools/call before the downstream tool executes, checks it against operator-delegated capability grants and hard ceilings under default-deny, allows or refuses it, and records the decision as signed, independently verifiable evidence. Other MCP methods pass through ungated — enforcement is scoped to the tools/call method class, and we say so rather than implying every agent action is governed.


One Product, Three Separable Planes

Each plane carries its own maturity, and they do not borrow credibility from one another. Multi-tenancy is a Human Plane property: it changes who may administer and review, not how a decision is gated, witnessed, signed, or verified. The Trust Plane remains one evidence universe per deployment.

Trust Plane

Proven today

The cryptographic core: the gate decides, the witness records, the receipt attests, and an independent verifier checks. Tenancy does not modify this plane — the trust core is one evidence universe per deployment.

  • Gate — default-deny evaluation before execution
  • Authority — operator-delegated capability grants and ceilings
  • Receipts — signed, hash-chained decision records
  • Witness — Merkle transparency log and signed tree head
  • Verification — a standalone verifier sharing no code with the server
  • Tamper evidence — altered evidence fails verification explicitly
  • External STH mirror — detects history rewrite, equivocation, and rollback once a tree head is mirrored; its anti-operator value depends on independent custody
  • Bounded assignment authority (stdio) — per-run grants with expiry, revocation, and a restricting operator-policy overlay

Human Plane

Supported, environment-gated · isolation substrate, identity boundary and per-request corridor merged, not production-active

Where people administer the system: who belongs to which organization, which agents and resources exist, and who may review the evidence. It administers Trust Plane objects; it never evaluates them.

  • Organizations, members, roles, and invitations — application-layer scoping, supported and environment-gated
  • Projects, agents, and resources — application-layer scoping, supported and environment-gated
  • Database-enforced tenant-isolation substrate — merged and CI-exercised; no shipped code puts the policies in force, not production-active by this program
  • Per-request corridor for the converted routes — merged and CI-exercised; it carries the tenant principal, it does not enforce row-level security
  • A provider-neutral identity boundary — merged and CI-exercised; no production identity provider is selected or activated
  • Policy administration surfaces — next
  • Evidence review and audit surfaces — next

Commercial Plane

Next — not built

The eventual commercial boundary: subscription, entitlements, usage, and billing. It gates commercial access to the product. It never grants an agent authority to execute an action.

  • Subscription and entitlements — next
  • Usage accounting — next
  • Billing — next

Billing controls commercial access. It never grants execution authority: tenancy scopes customer data, grants and policy govern tool authority, and receipts prove decisions.


Merged, Not Activated — the Production Multi-Tenant Human Plane

Organizations, members, roles, invitations, projects, agents, and resources exist in the Human Plane behind a hosting-environment gate. Three merged lanes have moved that tenant boundary down toward the database: committed, reviewable migrations instead of an owner-run schema push; provider-neutral PostgreSQL row-level-security policies keyed on a transaction-local verified principal, with adversarial cross-tenant isolation proofs running in CI; a provider-neutral identity boundary; and a per-request corridor that now runs the converted routes’ storage calls inside one transaction carrying that principal. What none of it does is switch the policies on. Provider-neutral is deliberate — the identity provider and the database vendor stay activation-time decisions rather than architectural lock-in.

Not yet production-active. Three Track-B lanes have landed on the main branch and are exercised by CI. Wave 1 is the isolation substrate: committed Human-Plane migrations, provider-neutral PostgreSQL row-level-security policies, transaction-local tenant-context primitives, and adversarial cross-tenant and schema-parity proofs. Wave 2A is the provider-neutral identity boundary: an opaque, permanent Magenta user identifier, a provider-agnostic identity adapter, and verified-email invitation authority. Wave 2B PR-1 through PR-5 is the per-request corridor: nine read routes and thirteen tenant-scoped mutations now execute their storage calls inside one transaction carrying the tenant principal, with the organization-family audit written in that same transaction. PR-1 through PR-5 themselves did not convert the two first-fact routes, organization creation and invitation acceptance — at the PR-1…PR-5 landing state those two routes remained on the compatibility path. Converting them, and wiring their first-fact database primitives, is Wave 2B PR-6, which has since landed on the main branch and is exercised by CI there. NONE of that is activation. Carrying the tenant principal is not enforcing a policy: the row-level-security policies bind only on a database where migration 0002 has been applied and the application runs as a non-owner role, and no shipped code performs either step. This project has applied no production migration, has selected and activated no production identity provider, and operates no hosted multi-tenant service. Wave 2B PR-7 and PR-8 — the runtime mode and startup admission, and the direct-add retirement — are not built, and activation itself remains a separate owner step after them. Because this is self-hostable software, these are statements about this project and this repository; what any independent operator has done on their own database is not something this repository can observe.


What Is Proven Today

The gate refuses a tool call unless a grant permits it; a blocked call never reaches the downstream tool, and the tool's own log corroborates its absence. Allow and block alike become Ed25519-signed, hash-chained receipts on a Merkle transparency log with a signed tree head. A standalone verifier that shares no code with the server re-derives the cryptography, and a tampered bundle fails verification explicitly. Under a bounded assignment the stdio gateway enforces the whole grant envelope — agent and run binding, activation window, expiry, revocation, explicit tool denial, grant integrity — plus a restricting operator-policy overlay. An append-only, hash-chained external STH mirror detects history rewrite, equivocation, and rollback once a tree head has been mirrored. Durable Postgres and file evidence ledgers, root-authority custody, and replay-nonce continuity exist as self-host, selector-gated mechanisms exercised by CI — they are not activated in the default deployment.

The stdio gateway enforces a bounded assignment when one is configured: the assignment becomes the whole authority for a single governed run, flat capability strings are ignored, and the decision runs through the grant envelope and a restricting operator-policy overlay. Operator policies may only restrict — they never widen a grant. A require-review decision is refused rather than allowed, because no human-approval path is wired. Without an assignment the gateway still gates, but on flat capability strings with no expiry, revocation, or run binding. The HTTP transport does not implement assignment mode and refuses to start if one is configured, rather than silently running on flat capabilities.

An append-only, hash-chained external STH mirror records signed tree heads outside the Magenta runtime. Once a tree head is mirrored, a history rewrite, an equivocation, a rollback, and an edit to the mirror file itself are detected and fail closed, and the evaluator packet runs this as an optional leg including the negative case. The mirror mechanism is implemented and proven: once a signed tree head has been mirrored, a history rewrite, an equivocation (two different roots at the same tree size), a rollback, or an edit to the mirror file itself is detected and fails closed. Its value against a dishonest operator depends entirely on independent custody — a mirror the operator also controls establishes nothing. It proves nothing about history before the first mirrored tree head, cannot recover a tree head lost before it was mirrored, and detects edits to the mirror rather than deletion of the only copy. What does not exist is a hosted, managed, independently operated third-party mirror service.

The identity seam on the HTTP evaluator is bounded in a way worth stating plainly. The HTTP evaluator's identity seam proves that an asserted principal label resolves against a static configured policy, that the call is gated against that principal's grant, and that the principal, grant, and decision are committed into the signed receipt — with an unknown or (in strict mode) missing principal failing closed before the gate. It is not identity verification: there is no token authentication, no SSO, and no mTLS, so it establishes which configured principal a call claims to be, not who actually sent it. Separately, a grant id is an unsigned canonical hash of the grant body — it detects an edited or stale grant, but it is not issuer authenticity and does not prevent forgery by anyone who can edit the envelope.


What Is Not Claimed

Not hosted production SaaS. Not a multi-tenant production platform — the database-enforced tenant boundary is being built now and is not activated anywhere. Not production identity-provider activation, and not a chosen identity vendor. Not billing, subscription, or entitlements — none of it is built. Not tenant-scoped evidence: the trust core is one evidence universe per deployment. No SOC 2, PCI, HIPAA, HITRUST, or ISO certification. Not legal, clinical, financial, or regulatory advice. Not a model-alignment or broad AI-safety solution. Not proof that a customer's policies are correct. Not proof of MCP method classes beyond the current tools/call proof. Not assignment enforcement on the HTTP transport, which refuses to start rather than run an assignment it cannot enforce. Not a wired human-approval path — a require-review decision is refused, not held. Not an independently operated mirror: a mirror the operator also controls establishes no independence, and no hosted third-party mirror service exists. Not authentication of the request sender — the identity seam resolves an asserted principal label, and a grant id is an unsigned integrity hash rather than issuer authenticity.


Deployment Posture

Private design-partner evaluation from a granted, repo-source checkout. There is no public package, no self-serve signup, and no hosted trial. A design partner evaluates Magenta from a granted private checkout, with mock tools, sample evidence, sector verticals, and explicit claims and limits. Public npm distribution remains withdrawn pending IP and licensing review.

The MDK is background architecture reference material, not a required public runtime and not the product surface. See the MDK reference if you have encountered its vocabulary elsewhere.