Verifiable Proofs for LLM Answers: Replacing Trust With Cryptographic Attestation

Once a large-model API call passes through several proxies, the caller often sees only a block of text and a set of response fields that can be rewritten. The invoice may name a premium model while inference actually ran on a cheaper one. A weak model can also be prompted with a target identity and claim to be that model. Common community checks—comparing style, inspecting response fields, or looking at chain-of-thought formatting—can at best suggest that the upstream service resembles a certain class of provider. They struggle to separate high- and low-tier models in the same family, and they cannot clear a provider that truly did not change weights when users complain that the model “got dumber.” Answer authenticity has long depended on trust. Attestation replaces “please trust me” with “please verify this cryptographic proof.”

What exactly must be proved

Attestation is not a decorative stamp on text. It binds the key facts of one inference run and has the party that holds the private key sign those facts. At minimum, the signed statement should include:

• Model identity: the model name or version sold to the customer, not an alias invented by a proxy.
• Input commitment: a hash of the system prompt, user messages, sampling parameters, and related inputs after canonicalization, so the same answer cannot be paired with a different question.
• Output commitment: a hash of the final visible text and, within the agreed scope, tool calls and the stop reason. For streaming, commit to the fully concatenated result.
• Policy statement: temperature, maximum length, whether mid-request model switching is allowed, and any other switch that affects whether the buyer received the contracted capability tier.
• Time and nonce: to shrink the room for replaying an old proof or attaching it to the wrong request.

The verifier holds only a public key or a public-key certificate. Anyone with the answer, the canonical form of the original request, and the proof can check, without contacting the inference node, that the signature is valid, the hashes match, and the model identifier in the statement equals the model in the contract. A failed proof means “origin not confirmed,” not “probably fine.”

A sketch can stay simple. Stable fields and deterministic encoding matter more than ceremony:

payload = canonical_json({
  model_id, model_version,
  request_hash, output_hash,
  sampling_policy, issued_at, nonce
})
proof = sign(vendor_signing_key, hash(payload))

Canonicalization must fix key order, whitespace, number format, and the digest algorithm for multimodal content. If the same logical request encodes twice into two hashes, format differences punch through attestation and also create large numbers of false alarms on legitimate traffic.

Three kinds of fraud, and how far a proof reaches

Model substitution. A proxy forwards the request to a cheaper model and returns that text unchanged. If the signing key is held only by the real model service, and the signature covers the contracted model identifier, the proxy cannot mint a valid proof for the premium model. At best it returns unsigned text, or a genuine proof from the cheaper model. The verifier compares identifiers and sees the mismatch.

Silent downgrade. Weights, system policy, or routing change while the public name stays the same. A signature alone proves only that some key holder attests: at that time, the version it declared was the one in use. It does not mathematically prove that the weight file is unchanged bit for bit, unless the version identifier is further bound to a weight commitment—for example, a publicly published weight hash that the inference proof includes. Without a weight commitment, attestation addresses impersonation and mislabeling, not a vendor quietly changing the model that keeps the same name. That limit must be stated externally. Otherwise attestation will be read as an absolute guarantee of capability.

Distillation and impersonation. Someone imitates the target model with a large set of conversations and serves it under the same name. Without the target vendor’s private key, a counterfeit service cannot produce a proof that verifies under the target public key. The reverse is also true: if every hop on the call chain can sign for itself, and the verifier trusts the wrong public key, attestation collapses into “anyone can certify themselves.” The trust anchor must be the model provider’s key, not a reseller’s key.

Attestation therefore has a hard prerequisite: the model provider must cooperate, and signing must happen inside the boundary where that provider still controls the model identifier. Signing only at the proxy layer proves the proxy’s claim, not the model’s origin.

Why existing heuristics are not enough

Asking the model to introduce itself hands identity judgment to a generation process that prompts can override. Style comparison depends on temperature, language, and task type, so both false positives and false negatives are high. Private response headers can be passed through unchanged or forged from documentation; header fields are usually not signed together with the body. Chain-of-thought formatting is unstable, and many APIs do not return reasoning at all. These methods are weak signals for operations alerts. They are not evidence for billing disputes or compliance audits.

Vendors have a matching problem. When users feel quality has dropped, and there is no version statement bound to the request, the official response can only be a verbal claim that the model was not swapped. With a publicly verifiable proof, the dispute becomes whether the signed version and policy hash match the release record for that day. The difference is evidence, not wording.

A verification path that can be deployed

1. Agree on canonicalization. Publish canonical rules for requests and responses, the hash algorithm, and the fields that must be signed. Optional fields are either inside the signature or explicitly excluded, so verifiers do not assume B was covered when only A was signed.
2. Keys and certificates. Keep the signing key separate from the online inference process. Use short-lived certificates or rotated signing keys. Publish the public key through the vendor’s own trusted channel, and support revocation. Intermediate proxies must not hold that private key.
3. Produce the proof. After inference, commit to the complete output and then sign. Streaming can send text chunks first and attach a proof over the full output on the final frame. The verifier reaches a final conclusion only after the stream ends.
4. Verify at the client or gateway. The application gateway verifies before storage, display, or billing by model tier. Failure policy must be written in advance: reject, downgrade to “unverified traffic,” or alert only. Do not treat failure as success by default.
5. Retain records. Store the proof, request hash, model identifier, and verification result for a period aligned with the billing cycle, so later spot checks are possible. If the body contains sensitive data, keep the hash and the proof; long-term storage of plaintext is unnecessary.
6. Sample and reconcile. Besides verifying all traffic, independently sample high-price model routes: for the same canonical request, does the model identifier match on a direct provider path and on the proxy path? Samples and decision rules must be repeatable. Do not rely on a subjective sense of whether the model seems smart.

If an organization already has a shared API gateway, key management, and audit logs, these steps can sit on those components. The gateway intercepts and verifies signatures, key management holds the trust anchor, and logs retain hashes and verification outcomes. Attestation does not require a new business protocol, but “verification passed” must not live only in an untrusted downstream field.

Limits and common misuse

Replay. A previously valid proof can be pasted onto a new request unless the request hash, time window, and nonce are inside the signature, and the verifier rejects expired proofs. Signing the output and not the input is the most common design mistake.

Partial edits. If a proxy rewrites a few words, the output hash should fail. If the business needs the gateway to append a disclaimer, keep that appendix outside the signed range and make the interface distinguish “model text” from “gateway addition.” Signing the mixture blurs responsibility.

Multimodal inputs and tools. If images, audio, retrieval results, or tool return values affect generation but are left out of the request commitment, an attacker can swap in another context and reuse the text proof. The agreement must state which side channels must be hashed.

Performance and availability. Hashing and signing usually cost far less than large-model inference, but an unavailable key can cause verification failures at scale. Plan for key rotation, tolerance of clock skew, and an explicit degradation policy. Monitor the verification failure rate. Do not silently skip verification during an outage.

Capability is not proved to be “equally smart.” Cryptography attests model identity and version. It does not prove that this sample meets the advertised level on every task. Quality still needs evaluation sets, human review, and version regression. Attestation addresses origin. Evaluation addresses capability. Do not substitute one for the other.

Privacy. Putting the full prompt into a proof that can be passed around widens exposure. Publish only the hash and leave the original text with the caller. Verification does not require handing user content to a third party.

Stronger proofs, including zero-knowledge proofs, can establish some statements without revealing weights or prompts, but circuit constraints, trusted setup, and engineering cost are higher. For most billing and anti-impersonation cases, a binding signature already closes the main fraud surface. Do not adopt heavier cryptography before the requirements are stable.

Checklist items for contracts and runbooks

• Where the public key is published, how often it rotates, and how historical proofs are handled after revocation.
• The list of fields that must be signed, and the list of fields a proxy is allowed to rewrite.
• Billing and refusal rules when there is no proof, the proof is expired, or the model identifier does not match.
• Whether streaming, retries, and cache hits may reuse an old proof. A cache hit must still correspond to the same request hash and the same model version.
• Distillation or resale: if a downstream service sends the user request on to an upstream model, it should keep the upstream proof and show the verification result to the end user, not replace it with the downstream service’s own identity claim.
• Incident response: when the verification failure rate spikes, first separate key outages, canonicalization version mismatches, and real substitution, so an entire product path is not blocked by mistake.

Summary

The authenticity of a model answer used to rest on brand, price, and feel. Verifiable attestation binds model identity, request, output, and policy into one signature, so model substitution and impersonation cannot be made consistent without the provider’s private key. It also requires provider cooperation, a clear trust anchor, and strict canonicalization. It does not automatically prove that weights never changed, and it does not automatically prove answer quality. Design the proof, evaluation, and key governance separately. Only then can a team answer a harder question on a relay path: for this paid call, was the origin actually verified?