You send a prompt to an API. You get tokens back. You have no way to establish that the model which produced them is the model you were billed for, that its weights were not quantised last Tuesday, or that the same version answered your two calls this morning.
Meanwhile a player on a crash game can take the result of a round they just lost, recompute it from published inputs, and confirm the operator did not touch it.
One of those industries is built entirely on trust. It is not the one with the verification scheme.
The Regulated Answer: Somebody Else Checks
Where a gaming regulator exists, verification is institutional rather than cryptographic.
Independent test houses examine a random number generator before a title ships. They run statistical batteries against its output, confirm the distribution matches specification, verify the declared return percentage, and issue a certificate that regulators accept. The statistical methods involved are standard and public, and the same families of test appear anywhere randomness needs auditing.
That regime reaches wherever a regulator operates, and something more interesting developed alongside it elsewhere. California maintains its own licensing framework for tribal casinos, card rooms and the state lottery rather than for online play, so platforms serving Californians hold licences from other jurisdictions and a growing number publish cryptographic proofs on top of that. Anyone wanting to explore options in California will find provably fair implementations widely used there, and on the argument that follows they are the stronger guarantee of the two. A certificate asks you to trust a laboratory you will never meet. A published seed chain lets you verify one specific round yourself, on your own device, in microseconds.
How Commit-Then-Reveal Actually Works
Provably fair is a commitment scheme, and the construction is worth walking through because it is genuinely elegant.
Before the round, the server generates a random server seed and publishes its SHA-256 hash. The hash is a binding commitment: finding a different seed producing the same hash is computationally infeasible, so the server is now locked to that value.
The player contributes a client seed. This is the crucial part. The server committed to its seed before seeing yours, so it cannot select a server seed that produces a favourable outcome against your specific input.
The outcome derives deterministically. Typically HMAC-SHA256 over the server seed, the client seed and an incrementing nonce, with the digest mapped onto the game’s result space. Same three inputs, same output, every time, on any machine.
After the round, the server reveals the seed. You hash it, confirm it matches the commitment published beforehand, recompute the outcome yourself, and compare.
Crash games extend this with a hash chain. The operator generates a long chain by repeatedly hashing, then plays rounds in reverse order of generation, so each revealed seed hashes to the previously revealed one. The entire future sequence is committed at chain creation. Alter any round and every subsequent verification breaks.
Why It Works: The Recomputation Is Free
Here is the property that makes the whole thing possible, and it is the reason the approach does not transfer.
Verifying a provably fair round costs one HMAC. Microseconds, on a phone, offline. The verification is cheaper than the game.
That is not incidental, it is load-bearing. A commitment scheme only helps if the committed-to computation can be independently reproduced by the person checking. When reproduction is trivial, you get verification for nothing.
What You Cannot Verify About an Inference Call
Now the comparison, and the list is longer than most people building on these APIs have thought about.
Model identity. A version string in a response is an assertion by the provider, not evidence. Nothing in the response cryptographically binds it to a particular set of weights.
Quantisation. A provider serving a lower-precision variant under load would produce outputs that are usually similar and occasionally not. There is no client-side signal.
System prompt. Anything prepended before your input is invisible to you and can change without notice.
Version continuity. Pinning a dated model string helps, and it is still a promise rather than a proof. Silent updates to serving infrastructure are not detectable from the output.
None of this asserts that providers are doing these things. The point is narrower and, for anyone building production systems on top, more uncomfortable: you could not tell.
Why Commitment Does Not Transfer
Two reasons, and the second is the harder one.
Reproduction is expensive. Recomputing an inference to check it requires the weights and comparable hardware. That is the opposite of an HMAC. Even if a provider published a hash of the weights, you could not use it to verify a specific response without running the model yourself.
Inference is not deterministic anyway. Set temperature to zero and you still will not reliably get identical outputs across calls. Floating-point addition is not associative, GPU kernels reduce in non-deterministic order, and kernel selection varies with batch size, which varies with whoever else is hitting the endpoint. Two identical requests can take different code paths for reasons that have nothing to do with your prompt.
So even the notion of “the correct output” is fuzzy in a way it never is for an HMAC. You cannot commit to a result you cannot reproduce.
What Would Actually Work
The direction that fits the problem is not commitment but attestation: proving what ran rather than proving what came out.
Confidential computing environments can attest to the code and data loaded into a protected enclave, with hardware signing a measurement that a remote party verifies. NVIDIA ships confidential computing on recent data-centre GPUs, and the same idea underlies secure enclaves on CPUs.
Applied properly, that gets you something like: this specific model, unmodified, ran inside an environment whose state was measured, and here is a hardware signature over that measurement. Which is a genuinely different guarantee from a version string in a JSON field.
It is also considerably harder, carries performance cost, requires trusting a silicon vendor’s root of trust, and is nowhere near default for public inference APIs.
The Uncomfortable Comparison
An industry whose users had no structural reason to extend trust went and built one anyway, precise enough that a stranger can audit a single round on their phone.
An industry that asks enterprises to route core workflows through remote inference offers a version string and a changelog.
The asymmetry is not because one set of engineers is smarter. It is because one problem admits a cheap check and the other does not. But that is an explanation rather than an excuse, and the gap is worth naming while attestation is still optional, because the argument for making it default gets weaker once everything is already built on trust.
Anyone building production AI systems should at minimum know which properties of their stack are verified and which are merely stated. Right now the honest answer for most deployments is that almost nothing is verified, and the security model is a contract rather than a proof.
