Trust

The vault

How much we hold, who can open it, and how you find out. The design is that nobody here can open your content alone at any tier, and nobody can open it quietly at any tier. Quietly is already impossible — every unseal lands in your own chain. Alone is what the second and third key holders end, and the box directly below names which of them the running software has.

The four tiers

The 2-of-3 seal, in detail

On zdr_escrow the data key is not wrapped to one party. It is split into three shares under a 2-of-3 threshold scheme:

• You hold one share.
• We hold one share.
• An independent escrow agent holds the third — named in your contract, and never a party we control.

Four consequences, each a property rather than a promise:

• We cannot decrypt unilaterally. Not "we have a policy against it" — we hold one share of three. An insider with full production access still cannot open your content.
• An investigation requires two parties to cooperate, which is a real procedural bar with a paper trail, and it satisfies the vendor obligation to be able to investigate.
• Every unseal — attempted, refused or completed — is a record in your own receipt chain, carrying the reason, the outcome and how many shares were presented. You cannot be investigated silently.
• The absence of an unseal is provable. Because the chain is complete and signed, "nobody opened anything last quarter" is something you can verify offline rather than something we assert.

The window is 72 hours by default and the ciphertext is destroyed on expiry, so even the worst case is bounded.

Where the content itself goes

How a request is sealed

1. The stream closes. We assemble the request, the response and any reasoning text the provider actually emitted.
2. We mint a fresh 256-bit data key and seal the payload with AES-256-GCM.
3. We wrap that data key to your KMS key — AWS KMS, GCP KMS, Azure Key Vault or an HSM you control. We never hold anything that unwraps it.
4. We write the ciphertext, and zero the plaintext before the request arena is released.

customer_bucket mode arrives with the object-store integration: step 4 writes into your own bucket via a role you grant, and we hold nothing at all — not the key, not the ciphertext. It is the mode we expect enterprises to pick and the one we will recommend. The router has no object-store integration today, in any mode, and step 3 wraps to our key because there is no other holder configured.

What we are honest about

Retention postures

Four values. Each one names the class of document and the verification date that would back it, and the rate card records, per endpoint, whether that document has been read — the “Evidence we hold” column below is the shape of the evidence, not a claim that we hold it. Your policy sets a floor; endpoints below it are removed from the candidate set rather than ranked lower. A fallback may never lower your posture.

“ZDR on all tiers where possible” is the honest phrasing, because it is not always possible: some models are served only on retaining substrates. We list those endpoints in the catalogue rather than hide them, and a policy with a ZDR floor simply cannot see them. A smaller catalogue that tells the truth is the entire pitch.

Security architecture

Compliance position

When any row changes we will date the change here rather than quietly swap the chip. A trust page whose history you cannot see is a marketing page.

Subprocessors

Under GDPR Article 28 you are entitled to know every party that processes your data, and to be told when the list changes. For a model gateway the subprocessor list is the set of endpoints traffic can reach — so we publish one document, not two that can drift.

The catalogue is the subprocessor list. Every row is a model vendor and a hosting substrate, with the jurisdiction that serves it and the retention terms we hold them to.

Infrastructure subprocessors — the parties that touch metadata rather than content — are separate and short:

Notice of any change: 30 days before it takes effect, with a right to object. A policy restricting posture or residency also restricts your subprocessor set — and every receipt names the endpoint that actually served you.

Resale standing

A question most gateways do not invite, so here it is directly. Reselling model API access is not automatically permitted: vendor terms vary on onward resale, some paths are explicitly designed for it, and others require a named agreement.

Service levels — two numbers, never one

Our uptime cannot exceed the union of our upstreams' for a model you have pinned. Publishing one blended figure would hide exactly that, so we publish two.

Both take their values from traffic, and there is none yet. Nothing has been measured because nothing is deployed — the 99.99% and 99.9% this page once printed were measurements of nothing. Neither is a contractual target either: we name an SLO once we can show the history behind it, and not before. The shape of the measurement is the part that is settled.

A policy allowing rung-1 fallback has a materially higher effective availability than one pinned to a single endpoint. You should be able to see that number for your own configuration before choosing, so the dashboard shows it — an honest SLA that doubles as the argument for a better policy.

Live figures and history: status.

Enforcement without reading your content

Metadata alone is not sufficient to enforce an acceptable use policy, and it is worth being exact about where it works and where it does not.

What metadata catches well: fraud, credential abuse, stolen-card credit purchases, and industrialised abuse operations — which have a traffic shape nothing else does. What it catches poorly: a low-volume, well-funded customer generating prohibited content. That is the case that ends companies, and no amount of concurrency-curve analysis finds it.

So enforcement runs on four content-blind signals plus a retention floor:

At zdr_absolute the last row does not exist, which is why that tier requires you to accept the enforcement duty contractually: AUP flow-down to your end users, a named responsible officer, and indemnity. The duty does not evaporate because the ciphertext did — it moves.

What we will not do at any tier: read prompts to moderate them as a matter of course, or retry a vendor's content-filter refusal on a different vendor to get around it. Routing around a filter would make us a laundering service for the thing the filter exists to prevent. Full policy: acceptable use.

An operator running their own router can add a content classifier on top of all of this. It is off unless they switch it on, and what it is allowed to write into your receipt is deliberately almost nothing — the classifier layer.

The classifier layer, and what a receipt may say about it

Everything above is content-blind. This is the one control that is not, and it is switched off unless an operator switches it on. A classifier inspects the request before it is routed, or the answer before it is returned, and the router obeys what it says — allow, flag, transform, or block. It is pluggable: the built-ins exist for testing and for the one policy that needs no model, and the real one is a process you supply, spoken to in one JSON line each way. Nothing is recompiled to change a policy.

$ prismux-router --classifier length --classifier-id demo.len \
      --classify-inbound --classifier-stance fail_closed
FATAL: the classifier configuration is incoherent: PostureUndeclared

What the receipt records, and what it must never record

A classifier's whole job is to look at content and say something about it. Recording what it said is therefore recording a function of your content — into a chain that is signed, durable and published. So every candidate field had to survive one question: does this tell a receipt-holder something about the content that the caller did not already observe from their own request and response? The caller has the content. A third party reading the chain does not, and that asymmetry disqualifies almost everything.

Two things are recorded. The classifier's id, which is configuration — identical on every request under one deployment, so it carries no bits about any particular one. And a mark per point, from a closed 9-variant list, every variant named after what the router did rather than what the classifier found:

absent off allowed flagged transformed blocked error_open error_closed skipped

This is what the block looks like on a real leg — measured on 2026-09-04, from a router running the built-in length classifier at the inbound point:

"classification": {"classifier_id": "demo.length",
                   "classify_inbound": "allowed",
                   "classify_outbound": "off",
                   "coverage": "complete"}

blocked is in that list. blocked_for_pii is not, and that distinction is the entire design. Also refused, each for its own reason:

Two limits worth knowing before you rely on this

An outbound classifier cannot run on a streaming response. The client has already rendered bytes before the last one arrives from upstream, so there is no moment at which the whole answer exists and nothing has been delivered, and nothing can un-send what was already sent. Under fail_open the receipt says skipped rather than implying a check that did not happen. Under fail_closed the request is refused outright, before anything is forwarded — measured on 2026-09-04, that refusal reads classification_impossible and tells the caller to drop stream or ask the operator to run the classifier fail-open. This mattered: the mark alone used to be the answer regardless of stance, which meant a fail-closed deployment served uninspected answers to any client that asked for streaming — fail-open behaviour wearing a fail-closed configuration, recorded honestly and therefore easy to miss.

A request blocked at the inbound point has no leg, so its receipt does not name the classifier. The classification block lives on a routing attempt, and a request refused before routing made none. You still get a signed receipt — measured on 2026-09-04 it read delivery: none, posture: refused and charged: 0.000000, and the error names classifier as the binding constraint — but the chain line for that refusal carries no classifier_id. It is a real gap and it is stated here rather than discovered.

A caller may send X-Prism-Classify: on to switch classification on for their own request. off does nothing: a policy the caller can disable from their own request is not a policy, it is a suggestion. An organisation can carry a standing requirement that forces both points on and forces fail_closed, and there is no expressible value of it that switches a point off or relaxes a stance — the same direction every other axis here travels.

Signing keys

Receipts are signed with Ed25519, over the receipt's own content hash. Started with --signing-key, the router prints one line at boot and tells you to pin it:

  signing     7d6d9778b3d96b3f ed25519pub:wD3QWek9ka1XmFWRPl2AmGu+oYAFMPAN0+BlP0chNxw=
              ^ pin this line; `prism verify <chain> --keys <file>` reads it verbatim

That is the whole key distribution story today, and it is deliberately the smallest one that works: the id is the same value every receipt carries as signing_key_id, and the file format the verifier reads is that line, unedited. The line you pin is the line the verifier consumes, with nothing to convert in between.

Key publication and rotation land with the first production deployment: /.well-known/prismux-signing-keys.json, and a rotation history beside it. Today there is one key, no deployment to serve it from, and no published rotation history because nothing has rotated. A rotated key still checks old receipts. If a signing key is ever compromised we publish the fact, the affected window, and a re-attestation of every receipt in it — the chain makes the scope of such an event computable rather than a matter of assurance.

Incident policy

• Notification within 72 hours of becoming aware of a personal data breach, to affected customers, with what we know and what we do not yet.
• Scope from the receipt log, not from guesswork. Records carry an interval, not a timestamp, precisely so “which requests were in flight concurrently on endpoint X between T1 and T2” is a query. A point-in-time log cannot express concurrency, and that is what makes an incident unscopeable.
• A public post-mortem for anything affecting integrity of the receipt chain, retention guarantees, or billing correctness — including what we got wrong and what we changed.
• Counters, not adjectives. Degradations already appear as published numbers before anyone writes a status update.

Reporting a vulnerability

Write to security@prismux.com. We will acknowledge within one business day and give you a substantive response within five.

We do not require an NDA to report, we will not threaten legal action against good-faith research, and we will credit you unless you prefer otherwise. If you find a way to make the receipt log contain content, or to make a fallback lower a retention posture without it being counted, we especially want to hear from you — those are the two claims this whole system rests on.