A verifiable privacy layer
for open models.

Four questions.

1. What model and software answered the request?
2. Who could read the prompt while it was processed?
3. Can payment be separated from the request it paid for?
4. Can the result be verified without exposing the request itself?

SEAL stands for Sidecar, E2EE relay transport, Anonymous credits, and Ledger of receipts. A fifth component, measured policy, defines any enabled filtering in a way a verifier can inspect. The goal is not to ask users to accept a privacy statement. The goal is to give builders a protocol for checking the environment, the keys, the payment credential and the receipt trail themselves.

Why this expansion matters

Open models create more choice. A developer can select a model, a host, a region and an inference provider instead of being locked to one closed platform. But that choice also creates a new trust problem: the request often crosses several systems operated by different parties.

A prompt can reveal unreleased code, research, trading logic, customer records or private instructions. The ordinary setup asks a user to trust the inference provider’s handling of that data while it is in use. For open-model infrastructure the underlying questions remain: what is actually running, where does plaintext exist, and what evidence can an independent party inspect?

Confidential computing is relevant because it is designed to protect data while it is being used, not just while it is stored or transmitted. NVIDIA describes confidential computing as hardware-level protection for GPU execution, memory, register state, model weights and inference prompts, with device attestation used to assess the trustworthiness of the compute environment. SEAL applies that direction to an open-model routing system, then joins it with encrypted transport, privacy-preserving credentials and receipts.

SEAL is not a claim that all privacy problems are solved today. It is a public working draft (v0.1.0), not an IETF standard, and its repository separates what is implemented from what remains planned in a status table that this page reads directly.

The design in one request.

A complete SEAL request is designed to work as a chain of independently checkable steps. First, a client selects the privacy floor it needs. SEAL specifies three lanes:

The router treats a lane as a floor. If it cannot meet a lane’s requirements, it refuses and explains why, rather than silently serving the request below the level it asked for.

1. 01 / Attested serving.

   The request reaches the model-serving environment. SEAL’s Sidecar measures the model weights at boot, checks them against an allow-list, creates its application keys in memory, and obtains hardware-attestation evidence that commits to those keys and measurements. The evidence binds the TLS key, the receipt-signing key, the model digest and configured deployment values into a verifiable record. A client can inspect that evidence, compare the trusted values, and pin the TLS key for the live connection.

2. 02 / Encrypted to the enclave.

   Where encrypted transport is enabled, the client encrypts the request body to an HPKE public key obtained from verified Sidecar evidence. The Sidecar can reject expired, replayed, malformed or undecryptable requests before they reach the model server. It can also encrypt the response in authenticated frames, so a client can detect a truncated encrypted response.

3. 03 / Paid without a name.

   For payment, the design introduces blind-signed credentials. Version 1 uses fixed-value Privacy Pass Blind RSA tokens. The router can validate a token at redemption without the generation record or the receipt naming the buyer; the receipt carries a nullifier and a token key id instead.

4. 04 / A receipt to check.

   The response comes with a signed receipt whose hashes let a client check the exact request and response bytes of the exchange, the model digest, the attestation reference and, where applicable, the policy state. Router receipt roots can be anchored on chain for later inclusion checks.

Privacy, payment and proof should not all depend on one provider’s internal database and one provider’s promise.

S Sidecar and attested serving.

The Sidecar is the model-side gateway. It sits next to an OpenAI-compatible model server and turns an endpoint into something that can expose evidence about its configuration. At boot it calculates a deterministic digest across the model files. It refuses to start if its model allow-list is empty or if the measured digest is not on it. It creates TLS and Ed25519 receipt keys in memory, then includes the public keys and measured values in the attestation binding.

The evidence is served at GET /attest. A verifier can request a fresh nonce-bound quote, recompute the binding digest, compare it with the quote, validate the hardware quote with a verifier of its choice, and make sure the live TLS connection uses the key bound in that evidence. Development evidence is labelled as such, and a verifier must reject it outside development.

This matters because “private server” is not a useful technical category on its own. A meaningful claim needs evidence about the endpoint, the model identity, the encryption key and the receipt-signing key.

There are boundaries. In version 1 the Sidecar’s image digest is an operator declaration, because a process cannot read its own image digest, and the compose hash is hardware-measured only where the platform reports it. Model weights are measured at boot and must be mounted read-only. A boot quote shows what booted, not that the same endpoint is still live later; fresh nonce-bound checks and TLS-key pinning are there for freshness. Version 1 evidence also does not bind GPU evidence into the Sidecar’s TDX quote. That is a material distinction, and SEAL documents it rather than presenting a CPU-side quote as complete proof of confidential GPU execution.

E Encrypted transport and network separation.

Encryption and network privacy solve related but different problems. SEAL’s anyroute-hpke/v1 mode encrypts the request body from a client directly to an enclave Sidecar, with HPKE over X25519, HKDF-SHA256 and AES-128-GCM. The request path and the client’s time are bound as associated data, and the framed, encrypted response lets the client check that the final frame arrived.

Separately, the system has an Oblivious HTTP gateway and relay design. The relay drops ordinary client headers, cookies, addresses and query strings before it forwards the encapsulated request. The unlinkable lane requires a blind token and either an independent relay or Tor onion access; a relay run by the gateway’s own operator is explicitly not enough for that lane.

The distinction matters because encrypted content alone does not hide every signal: network participants can still observe timing and size. And the path through the router matters as much as the cipher. Whether the router carries the client’s inner ciphertext through to the enclave on the attested and unlinkable lanes, or terminates TLS and sees the request, has its own row in the status table, as do chunked Oblivious HTTP, padding and fixed-send timing for streamed traffic.

That disclosure is not a weakness in the specification. It is exactly why a public specification needs a status table: builders should be able to choose a privacy lane knowing what it guarantees now, not what a roadmap may guarantee later.

A Anonymous credits.

Payment can be a privacy leak even if the request body is encrypted. If the account that buys access is attached to every inference call, payment history becomes request history.

SEAL’s version 1 credits are Privacy Pass Blind RSA tokens. A buyer submits blinded token material and the issuer signs it without learning the eventual token. When the token is redeemed, the router verifies the credential, claims a one-time nullifier so it cannot be spent twice, and bills a pooled internal account. The receipt and the generation record can carry the nullifier and the issuer key id without naming the buyer.

These tokens have deliberately narrow economics: they are fixed-value, single-use credentials. A request cannot cost more than the token’s value, and unused value is not returned as change. The more flexible e-cash design, with variable value, blinded change, holder locking and a DLEQ proof on every signature, is specified alongside them in 0003.

Blind credentials do not erase every correlation risk. Privacy depends on the size and behaviour of the anonymity set; buying and at once spending a distinctive token shrinks it, and a transparent funding rail can still identify the buyer at purchase time. A protocol should describe these limits instead of using “anonymous” as a blanket label.

L A ledger of verifiable receipts.

A private system still needs accountability. SEAL’s answer is a receipt that proves facts about an exchange without putting the prompt or the response in the receipt.

The version 1 node receipt is signed with Ed25519 and carries hashes of the exact request and response bytes, the model digest, the attestation reference, usage, completion state, and optional fields for an encrypted exchange or the classifier. JSON responses carry it in a response header; streamed responses deliver it after the stream’s final event.

The router also signs receipts for the generations it settles: the model, provider, cost, latency, lane, attestation details and payment fields. Its signing keys are published and, where a chain is configured, registered on chain and never overwritten. Receipt leaves are collected into hourly Merkle trees whose roots are posted on chain where a chain is configured, so a user can verify inclusion against the anchored root.

This does not mean a receipt proves that a particular model computed an answer. A valid node receipt proves that a process holding a key bound to a verified quote signed the stated hashes; the broader conclusion about the serving environment rests on attestation. An anchor proves inclusion in the anchorer’s tree, not that every possible receipt was included. The purpose of receipts is to turn more of the inference path into an inspectable record, not to manufacture certainty where the technology cannot provide it.

Measured policy: visible constraints, not hidden filters.

Open-model infrastructure also has to be clear about policy. A host may need to refuse certain requests, but an opaque filter undermines the promise of an inspectable system.

SEAL’s optional classifier runs inside the enclave when it is turned on. Its weights are allow-listed separately and measured at boot. Whether it is on, its digest, the policy hash and the categories behind it are tied to the attestation record, so a verifier can see whether filtering was active and what policy was measured.

The policy layer is intentionally narrow. It has a built-in minimum category for sexual content involving minors; operators may add publicly described categories, but cannot remove or redefine the built-in one. The classifier can check request text and, optionally, response text. It keeps counters, not the request text, the category or the label. A blocked request gets a signed refusal receipt with no content in it.

It is not a magic safety solution. The classifier is off unless the operator turns it on, can make false-positive and false-negative decisions, and does not examine images, audio or files in version 1; requests that carry them are refused by default or let through, as the measured configuration says. A policy hash proves which policy and classifier were measured, not that the classifier decided perfectly. For users of open and less centrally curated model ecosystems, this is the useful direction: constraints should be visible, measurable, and limited to what the system says they are.

Who learns what.

The parties to a request on the full design, and what each can and cannot learn. This is the design’s intent; the status table says which parts of it exist, and the honest limits below say where it stops.

Honest limits.

These hold for the design, not only for today's code, and are published with it.

• Trust rests on Intel, AMD and NVIDIA silicon, reproducible builds and witnessed logs. It is not a cryptographic proof of inference.
• GPU attestation on shipping Hopper and Blackwell parts proves a genuine confidential-computing GPU is reachable. It does not bind that GPU to the confidential VM (no TDISP yet). Physical memory-interposer attacks on DDR5 are out of scope.
• AMD SEV-SNP hosts cannot carry confidential-GPU claims yet: SNP has no runtime measurement register to bind GPU evidence into.
• Unlinkability holds against Anyroute, against hosts and against any single relay. It does not hold against a relay colluding with the gateway, or against a global network observer correlating timing.
• On the Tor path of unlinkable, Tor takes the place of the independent relay. Anyroute runs the onion service and never learns the client's address, because a Tor onion service is never given it. Ordinary chat exposes plaintext to Anyroute’s router; the distinct encrypted-chat adapter forwards encrypted content to the gateway enclave. Anyroute sees clear routing metadata and request size and timing directly, with no relay in between. An observer who watches both the client's entry into Tor and the router's side can match them by timing, and requests sent on one Tor circuit can be linked to each other.
• Deterministic (batch-invariant) serving and confidential-computing mode both cost throughput.
• Credits are non-transferable prepaid inference, not money and not an investment.
• A minimal, measured block list runs inside the enclave and its hash is public. Nothing else is filtered.
• Stylometric identification from prompt content is out of scope: the protocol hides the channel, not what you write.

Design targets.

These are the properties SEAL is designed to provide once every part in the status table below is built. They are targets, not claims about today's deployment; the status table says which parts exist.

G1

Attested execution. A request is served only by an enclave whose CPU quote and GPU evidence match a publicly logged manifest.

G2

Weights identity. The digest of the served weights is measured at boot and named in every receipt.

G3

Confidentiality. Plaintext exists only in confidential-VM memory and confidential-GPU memory; requests are encrypted from the client to a key the enclave's evidence binds.

G4

Unlinkable payment. The credit issuer cannot link a purchase to a redemption, and a DLEQ proof shows it signed with the published key rather than a per-user one.

G5

Network privacy. On the unlinkable lane the client's address is hidden from the router by an Oblivious HTTP relay run by another operator, or by Tor when the request reaches the router's onion service.

G6

Verifiable receipt. Each response has a signed receipt with request and response hashes, a hash chain over streamed chunks, the execution profile and the policy hash; receipt roots are anchored on chain.

G7

Verifiable policy. What the enclave blocks is defined by a measured policy document whose hash is public; nothing else is filtered and no content is logged.

G8

No key partitioning. Every key or configuration a client encrypts to or verifies against is in a witnessed transparency log, and clients refuse keys that are not.

What exists today, and what remains planned.

SEAL is most useful when its present state is described accurately, so this table is not written for this page. It is read from the spec’s own status table when the site is built, row for row.

31 rows: 23 implemented (10 of them off by default), 8 planned. Source: spec/README.md, Status of this repository.

Implemented is not the same as switched on.

The table above is about the repository. This panel is about the router serving this page: what it reports about itself right now in its public status document. Anything it reports as off says so.

Encrypted chat and automatic host admission are switched on at anyroute.tech. Bonds are indexed from HostBond; payouts, fee buy-and-burn and slashing are not switched on yet. The live panel below reports the router’s current status.

Why a public specification changes the ecosystem.

The spec/ folder is licensed under Apache-2.0, even though the rest of the repository keeps its own source-available license. The five RFC-style documents describe attestation, transport, anonymous credits, receipts and verification, and measured policy in a form third parties can review or implement without treating Anyroute’s codebase as the only source of truth. That matters for builders in three ways.

The larger point.

Open models should not require open exposure.

More broadly, neither model access nor privacy should be decided by whether a user is willing to trust a server operator they cannot inspect.

SEAL is Anyroute’s effort to give open-model infrastructure a verifiable privacy layer: prove the serving environment where possible, encrypt the request path where implemented, separate payment from request history where blind credentials support it, publish the policy, and return receipts that users can inspect later.

The protocol is still early. Its strongest claims are the ones marked implemented above, because a builder can check them. Its most ambitious outcome, an end-to-end unlinkable lane that combines independent relay transport, encrypted requests through the router, attested execution and blind e-cash, depends on every one of those rows, and the table, not this page, says how far along each one is.

That is the right posture for infrastructure of this kind. Build the critical pieces in public. Specify the rest in public. Mark the difference. Then let builders, model hosts and users verify the system as it grows.