
Technical Overview
The gateway in engineering terms: architecture, request lifecycle, cryptographic artifacts, evidence and verification.
PDF · 24 pages · 1.3 MB · QODIQA-TO-1.0 · v1.0
Download PDF
SOC 2AICPA Trust Services CriteriaProduct · Architecture
Follow one request through the execution boundary: verified, decided, recorded and receipted. Every diagram below plays by itself on a loop, and its parts can be selected.
1 · The big picture
One request, from the application to a receipt that anyone can check, with the AI provider called only when every check has passed.
The application asks the gateway to sign a permission for one exact request, then sends both together.
The gateway checks the artifact, asks the policy engine about consent, writes its intent to the record, and only then calls the provider. The answer comes back with a signed receipt.
A request nobody authorised never reaches a model, and its intent is recorded before the call.
If the intent cannot be recorded the call is not made. Most refusals are recorded too, so they leave evidence just as an answer does (the exceptions are listed below).
The receipt names one audit entry and one transparency-log leaf. A verifier can check it on its own machine.
A verifier holding the right public keys needs no help from the gateway. Section 6 shows how.
Requests that fail the input guards, cannot be decoded, or are rejected by the artifact checks (signature, time, key status) are counted but are not written to the audit chain or the transparency log. Rejections from the request-binding check onward are recorded. This is why the "blocked" variants above end differently.
A record proves that the gateway recorded a decision. It does not prove the decision was right, and the operator vouches for the evidence unless an independent witness or anchor is used.
2 · The seven stages
The first check that fails ends the request, writes the reason, and leaves the provider dark: no model call, no partial answer.
Ingress guards run first, then validation, the artifact check, consent and policy. Only then is the provider called.
The artifact is proven genuine, fresh and bound to this exact request. Afterwards the answer is checked and the decision becomes evidence.
The order is enforced: a failed check stops the request. A missing store, an expired artifact or a revoked consent ends in a refusal.
An unwritable audit entry also ends in a refusal, never in a silent pass. Choose a failure below and watch the line stop.
Every stage and outcome code here is the one the simulation uses.
In the simulation you can run each case with real cryptography, inside your browser.
| Stage | What is checked | Outcome codes when it fails |
|---|
The seven stages are a way of grouping the steps the gateway documents (input guards, artifact decoding, artifact validation, request binding, nonce registration, burst detection, policy, provider execution, audit write, transparency leaf). The gateway itself does not use the word "stage" for them.
Policies run in the order the tenant configured, and the first denial wins. A refusal is returned as a decision (HTTP 200 by default); the operator can switch to class-based HTTP statuses. An optional content check can sit between policy and provider; it is off in the sandbox and is not drawn here.
3 · The consent artifact
Five fields, one Ed25519 signature, a fingerprint of the exact request it allows, and a validity that expires within sixty seconds.
The gateway fingerprints the method, path and body, puts the fingerprint in the artifact and signs it.
The signed artifact travels with the request in a header.
Change one byte of the body and the artifact no longer covers the request.
The fingerprint no longer matches. Use the artifact twice and the second use is refused. Wait too long and it has expired.
The fingerprint is a plain SHA-256 over a published canonical form. Try it on the right.
The values are computed in your browser from the prompt shown, with the same function the simulation uses.
Five fields: expiry, payload, publicKeyId, signature, timestamp. Lifetime at most 60 seconds. Single use. The payload carries a hash of the exact request.
envelopeHash = SHA-, and the signature is Ed25519 over that 32-byte digest.
requestHash = SHA-. In the first protocol version it binds method, path and body, not headers or the query string; a later version can bind more but is off by default for issuance. Each hash starts with its own label, so a hash made for one purpose cannot be mistaken for another.
4 · The evidence stack
A hash-linked audit chain, a Merkle transparency log with inclusion proofs, signed checkpoints, and a receipt that points at both.
Each decision becomes an audit entry that hashes the one before it, and a leaf in a Merkle log.
The log's signed root lets anyone prove the leaf is in it. A signed receipt names the entry and the leaf.
Editing an old entry changes its hash, which breaks every link after it.
A log can show a leaf is included without showing the other leaves. A signed checkpoint vouches for the head of the chain at a regular position.
Play "Verify", then try the real Merkle proof below. The records hold hashes, never the prompt text.
So the evidence can be shared without the content.
An inclusion proof recomputes the path from one leaf to the signed root using only the sibling hashes.
entry.; the first entry points at GENESIS. The Merkle log follows RFC 6962 with SHA-256, a 0x00 prefix for leaves and 0x01 for inner nodes. A receipt is {v, requestId, decision, issuedAt, entryHash, leafHash, keyId, signature}.
The audit hash is unkeyed, so on its own it detects accidental or partial edits. Rewriting the whole chain is caught by a signed checkpoint, a signed leaf or an independent anchor, not by the chain alone. The Merkle explorer uses illustrative entry hashes, not real gateway data.
5 · Trust domains and keys
Artifact keys, transparency-log keys and checkpoint keys are separate Ed25519 key sets, so a leaked key in one domain gives you nothing in the other two.
Artifact keys sign consent artifacts, transparency-log keys sign Merkle roots, checkpoint keys sign checkpoints.
Each set has its own key file and its own lifecycle: keys can be rotated, deprecated or revoked.
Forging an artifact, a log entry and a checkpoint are three different jobs that need three different keys.
There is one algorithm, Ed25519, and no negotiation, so there is no weak option to downgrade to.
The artifact and transparency key sets are published as public key lists you fetch over a channel you trust.
Give them to the verifier. Never take them from the evidence you are checking.
Separate domains limit what one stolen key can do. They do not remove the operator from the trust path: unless an independent witness or an external anchor is used, the operator who runs the gateway vouches for all three. Verification is circular if the keys and the evidence come from the same instance.
6 · Offline verification
The verifier reads two files, runs seven checks in order, and answers VALID or INVALID. It makes no network call and imports nothing from the gateway.
The verifier checks the receipt's shape, version and fields, then the signing key, the signature and the key's status.
The key must be in the set you trust, and the signature is Ed25519. The first failure wins and names its reason.
You do not have to trust the gateway's code to check its receipt.
A tampered decision, an unknown key or a revoked key each fail in a different, named way.
A valid receipt says a trusted key signed a record of one decision for one request.
It does not say the decision was right, or that the keys you trusted were the right ones. Try the same check in the verifier.
| Check | What is tested | Reason on failure |
|---|
The public verifier repository includes recorded sessions you can check without a gateway. Exit code 0 means valid, 1 means invalid.
node bin/verify.bundle.external.js \
--keys examples/front-half/keys.json \
--transparency-keys examples/front-half/transparency-keys.json \
examples/front-half/bundle-with-proof.json
# exit 0 = VALID7 · Streaming and agents
Streamed answers and agent tool calls pass through the same front-door checks. What changes after that is shown here.
The five request checks run before the stream opens; a failed check returns a plain refusal and no stream.
When output inspection is on, the answer is held in a small buffer, checked, and only then released to the client, window by window.
Each tool call needs its own action artifact, bound to the exact call, and goes only to registered servers.
A delegation can hand on only a subset of its own rights. Tools that need it require a human approval tied to that exact action.
Both paths leave evidence: for streams, that the request was authorised and how many bytes were sent.
The audit record does not hold the streamed text. For tool calls, the gateway records intent and commit entries for the action.
Delegation tokens and chains in the public repository define the checks shown above.
8 · Read next
Four places to continue, from the product to the normative documents.
What the open-source gateway does, how to run it, and its stated limits.
Open the gateway pageHow checkpoints can be anchored outside the operator's control.
Open anchorsThe normative documents behind every hash and signature on this page.
Browse the specificationRun a simulated session in your browser and verify the evidence it produces.
Run a simulation
The gateway in engineering terms: architecture, request lifecycle, cryptographic artifacts, evidence and verification.
PDF · 24 pages · 1.3 MB · QODIQA-TO-1.0 · v1.0
Download PDF