Bringing Blockchain to the AI Gateway

Every AI product you use today asks you to trust a black box. You send a prompt, sometimes containing a customer record, a piece of unreleased code, a legal draft, and a server somewhere processes it and hands back an answer. You have no way to check which model actually ran, whether your input was read by a human, or whether the response was quietly generated by something cheaper than what you paid for. The entire relationship rests on a company's word.

Blockchain spent fifteen years solving a version of this exact problem for money. Not the price chart, not the trading, the actual engineering problem underneath it: how do you get two parties who don't trust each other to agree on a shared set of facts, without a middleman either party has to trust? Bitcoin's answer was a public, append-only ledger that anyone could read and no single party could rewrite. That idea, stripped of the currency and the speculation, turns out to be exactly what AI infrastructure is missing.

That's the premise SafeRouter is built on. Not a token, not a chain, not a marketplace. The trust model, applied to the thing that actually needs it: what happens to your prompt between the moment you send it and the moment you get an answer back.

What blockchain actually solved

Strip away the price action and a blockchain is three specific engineering ideas working together:

• Tamper-evident history. Every new entry is cryptographically linked to the one before it. Change anything in the past and every entry after it stops matching. You don't have to trust that nobody edited the ledger. You can check.
• Public verifiability. Anyone, not just the parties involved, can independently confirm the ledger is internally consistent. Verification doesn't require permission or a relationship with the operator.
• Proof over promises. The system is designed so a dishonest operator gets caught by the math, not by an audit six months later. Trust is a property of the protocol, not a property of the people running it.

None of that requires a consensus mechanism, a native token, or a distributed set of validators arguing about block time. Those are the specific tools Bitcoin and Ethereum used to apply the three ideas above to a currency, where the hard problem is who gets to write the next entry when nobody's in charge. An AI gateway has a different hard problem. There's already an operator, us, and the question isn't who gets to write the log. It's whether you have to trust that operator to write it honestly.

Why AI gateways have this problem worse than most software

A router that sits between you and a language model is in an unusually powerful position, and an unusually invisible one.

It can silently swap the model you asked for a cheaper one and still return a plausible-looking answer. Output quality degradation is hard to notice on any single response, and there's no standard way for a customer to prove after the fact which model actually generated a given completion.

It can read everything that passes through it. Prompts routinely carry information nobody intended to publish: internal documents pasted in for summarization, customer PII in a support ticket triage flow, proprietary source code sent for review. A conventional API gateway processes that content in plain memory on a server the operator fully controls, which means the operator's word is the only thing standing between your data and someone with access to that server.

And it can rewrite what you sent, or what the model sent back, on the way through. Prompt injection isn't only something attackers do to you. An operator with access to the request path could do it to you too, and you'd have no way to tell the difference between the model's actual output and a version someone touched in transit.

In every one of these cases, the honest operator and the dishonest one look identical from where you're standing. That's the gap blockchain's trust model exists to close.

Picture a support team routing customer tickets through a language model to draft first-pass replies. The tickets contain names, order histories, sometimes payment disputes. Someone on that team has to sign off on sending that data to a third-party API, and the sign-off is almost always based on a page of prose: a privacy policy, a security whitepaper, a SOC 2 badge. None of that page proves anything about the specific request sent at 3:47pm on a Tuesday. It's a description of intended behavior, not a receipt. The team is trusting the description matches reality, indefinitely, for every request, with no way to spot-check any individual one.

The incentive problem compounds this. A gateway operator's margin is the difference between what a customer pays and what the underlying model costs. Quietly routing a fraction of traffic to a cheaper model, especially on requests unlikely to get closely scrutinized, is a lever that's available and that nobody on the outside can detect without independently re-running every request against every candidate model and comparing. That's not a realistic check for most customers to perform. It has to be structurally impossible, or at minimum structurally detectable, rather than something a customer hopes isn't happening.

Why this matters more as AI stops having a human in the loop

The trust gap above is bad enough when a person reads the output before it goes anywhere. It gets worse as more of this traffic comes from autonomous agents making API calls on their own, chaining decisions, taking actions, moving funds, without a person reviewing each individual response. An agent that gets a subtly wrong answer from a swapped model doesn't know to be suspicious. It doesn't have the human instinct of "that doesn't sound like Claude" or "this response feels off." It executes on whatever it received, at whatever confidence the response implies.

That's the actual reason we think this problem is urgent rather than theoretical. As more of the economy runs through agents transacting with each other and with AI infrastructure directly, the missing piece isn't a smarter agent. It's a way for every party in that chain, human or agent, to check what actually happened at each step without having to trust the operator in the middle. That's a verification problem before it's an intelligence problem, and it's the one we started with.

What we actually built

We didn't put SafeRouter on a chain. We took the three ideas, tamper-evident history, public verifiability, proof over promises, and applied each one to a specific point where trust was previously required on faith.

Your prompt is processed somewhere we can't see either

SafeRouter runs inside a hardware-encrypted enclave using AMD SEV-SNP, deployed today on real confidential-computing hardware, not a simulated mode. The CPU encrypts memory for the process handling your request. Not just at rest, while it's running. Our own infrastructure operators, the cloud provider, and anyone with root access to the box cannot read what's inside that memory. This isn't a policy promise about who we choose not to look. It's a hardware boundary that makes looking impossible, which is a fundamentally different guarantee than "we don't log your prompts."

You can verify which code is actually running

Before you trust an enclave, you need proof it's running the code it claims to be running, not a tampered build with a logging hook quietly added in. That's what attestation is for. SafeRouter's enclave produces a cryptographic quote, a signed statement of exactly which binary is executing, that anyone can request from /attestation/quote and check against the published verifying key. This is the same category of proof as a blockchain client verifying a block header against the chain's consensus rules: you're not taking anyone's word for what's running, you're checking a signature.

Every call gets a permanent, tamper-evident record

This is where the ledger idea shows up most directly. Every single API call, not a sample, all of them, gets written into an append-only, hash-chained transparency log. Each entry cryptographically references the one before it, exactly like a blockchain's block-to-block linking. If anyone, including us, tried to alter or delete a past entry, every entry written after it would fail to verify. The log is walkable from /attestation/transparency/head, and we don't hold the only copy: entries are periodically anchored to Sigstore's Rekor, a public transparency log used across the software supply chain industry, so the record doesn't depend on us keeping our own books honest.

Your own request carries its own proof

Every response from SafeRouter comes back with evidence headers: x-saferouter-call-id, x-saferouter-response-sha256, x-saferouter-tee-quote-id, x-saferouter-log-index. Take any one of those and hit /v1/calls/{call_id}/proof and you get back everything needed to independently recompute the hash chain around that specific call and confirm it matches the response you actually received. You don't have to ask us to check our own work. You do the check yourself, with public math, the same way a blockchain explorer lets you verify a transaction without asking the exchange that processed it.

Bringing your own key doesn't mean giving up the guarantees

Some customers already have direct contracts and volume pricing with a model provider and want to keep using their own API key rather than ours. That shouldn't mean stepping outside the trust boundary. A customer-supplied key is sealed the moment it reaches the enclave, and it's only ever released back out to an attested SafeRouter binary, meaning even our own operations team can't extract it and use it outside the enclave's control. The same hardware boundary that protects your prompts protects your credentials.

How this differs from a compliance audit

Most infrastructure trust today is backward-looking. An auditor samples a set of logs, checks a set of controls, and issues a report covering a period that already happened. It's a real and useful process, but it has a structural gap: the thing being checked is the operator's own records, and the check happens well after the fact, on a sample, not on the request that matters to you.

A transparency log flips both of those. The record is checkable in real time, on the exact call you care about, by you, not by a third party you also have to trust. And because each entry is cryptographically bound to the one before it, there's no version of "the logs for that period were incomplete" that goes undetected. A gap or an alteration in the chain is visible by definition, not by luck of the sample.

What we didn't borrow

It's worth being precise about where the analogy stops, because overclaiming it would defeat the entire point of a project built around verifiability.

There's no token. No mining, no staking, no gas fees. We're not asking anyone to hold anything or speculate on anything. There's no distributed validator set voting on the state of the world, because there's no adversarial multi-party consensus problem to solve here: there's one operator, and the question is whether that operator's actions are checkable, not who gets to be the operator. Decentralization solves a coordination problem between mutually distrusting parties who all want to write to the same ledger. That isn't our problem. Our problem is narrower and, we'd argue, more directly useful to solve: can a single operator's claims about what happened be checked by someone with no relationship to that operator at all. Public logs, cryptographic attestation, and hardware-enforced isolation get you there without needing a chain.

Where this goes next

Rekor anchoring already gives every call a public, third-party-witnessed checkpoint. The next step we're building toward is periodic on-chain anchoring of the transparency log's Merkle root, giving the log a second, economically expensive-to-forge witness beyond Rekor. We're also working toward reproducible builds, so the attestation quote doesn't just prove which binary is running, it proves that binary was built from the exact source on GitHub, closing the last gap between "you can verify the code is unmodified since it started" and "you can verify the code is exactly what's in the public repository."

None of that changes the core bet: that AI infrastructure earns trust the same way good cryptographic systems always have, by making dishonesty something the math catches, not something a customer has to hope doesn't happen.