You Cannot Manage a Model You Cannot Name
On 19 August, Stripe acquired OpenRouter in a deal reported above seven billion dollars. The logic is sound and the price tells you how sound: OpenRouter had become the default neutral gateway to hundreds of models, and routing a request to the cheapest model that can handle it is a real and large business.
Something else follows from that, and it has had far less attention. If a layer picks the model for you, per request, on criteria that change, then the identity of the model that served any given call is no longer a decision you made. It is an outcome you received.
One industry analyst put it more bluntly than any vendor would: enterprises are no longer making a clear, deliberate choice about which AI model they adopt.
Identity became dynamic. Obligations did not.
Plenty of duties still attach to the specific identity of a model, and several of them attach to where it came from rather than how it performs.
- Federal contracting. The FY2026 NDAA requires the Defense Department to exclude certain named AI developers from its systems, and prohibits contractors and subcontractors from using them in contract performance. That obligation flows down a supply chain.
- Export control. Prompting a model hosted in another jurisdiction with controlled technical data is best analysed as an export, requiring authorisation. Where the model runs determines whether an export occurred.
- Entity listings. Some model developers sit on restricted-party lists, with a presumption of denial attached.
- Sector rules. Model risk guidance in financial services, and high-risk classification under the EU AI Act, both attach duties to particular models rather than to an abstract capability.
Notice what these have in common. None of them asks whether a model is good. They ask which one it was. That is a question about identity, and identity is exactly what a routing layer abstracts away in exchange for efficiency.
The problem is proving a negative
Consider a company whose federal contract prohibits a named model family anywhere in contract performance. The compliance question is not "which models do we approve." It is "can we demonstrate that none of those models touched this work."
Try answering it with what most organisations have. A model catalogue lists what was approved, not what executed. A vendor attestation says what the vendor intends to serve, written by the vendor. A routing configuration describes policy at the moment someone read it, not behaviour at the moment a request was served. An invoice aggregates. Monitoring watches outputs, and a substituted model of similar quality produces outputs that look entirely normal.
None of these is evidence about a specific inference. They are descriptions of a system, offered in place of a record of what the system did.
And the negative is the hard direction. Proving that something did happen is a matter of producing the record. Proving that something did not happen, across millions of calls over eighteen months, requires a complete and trustworthy record of everything that did.
What an attestation cannot carry
The reasonable response is to push the question at suppliers: add a clause, demand a representation, require notice of model changes. Those are worth doing. They also have a ceiling, and it is the same ceiling every time.
A supplier attestation is the supplier's account of its own behaviour. It can be entirely sincere and still fail, because the thing being attested is not observable by the party relying on it. If the supplier itself routes to sub-providers, the attestation is a claim about a claim. Each hop adds a promise and removes a fact.
Identity is a runtime fact, so record it at runtime
The alternative is unglamorous. Capture the identity of the model at the moment of execution, bind it to the input and the output of that specific call, and have the record signed by a party that did not run the job. Then the answer to "which model served this request" stops being a reconstruction and becomes a lookup, and the answer to "did a prohibited model ever serve one" becomes a query against records you hold rather than a request to a supplier.
The reason this has to come from outside the execution path is structural rather than technical. A router that chooses the model, or a provider that serves it, cannot be the independent witness to its own choice. That is not a comment on anyone's integrity. It is the same reason auditors do not work for the department they audit.
What a receipt does not do
It does not tell you a model is safe, appropriate, well aligned or permitted. It makes no judgement about any provider or any jurisdiction, and it takes no position on which models an organisation should allow. Those are policy questions, and they stay with the people whose job they are.
What it supplies is the fact those policies depend on. A rule about which models may be used is unenforceable if nobody can establish which model was used.
The cheap layer and the missing one
Routing is now a seven billion dollar layer of the stack, and it deserves to be. It made inference cheaper and more available, which is good for almost everyone.
It also made model identity a runtime outcome rather than a procurement decision, at precisely the moment when more obligations than ever attach to that identity. Those two facts belong together, and at the moment only one of them has been funded.
Cyberian Systems is the verification layer for AI inference, issuing independent cryptographic receipts that bind the exact model, input and output of every inference — live in production today. Write to philippe@cyberiansystems.ai.