LLM Output Authentication: How to Verify Response Authenticity and Detect Model Degradation

1. The starting point: a trust gap in the LLM API call chain

In the production deployment of large language models, there is a long-standing “invisible link” between application providers and inference-service providers. Enterprises usually purchase a certain tier of model capability, but the actual responses they receive have been processed by gateways, aggregation layers, caching layers, quantization deployment layers, and other components. When billing is based on tokens while quality is measured by subjective experience, the two sides naturally face asymmetric information.

Three common types of trust failures in the industry can be abstracted as follows:

1. Model substitution: claiming to call a higher-tier model while actually forwarding the request to a lower-cost, lightweight model.
2. Capability degradation: the model identity may be genuine, but output quality is quietly reduced through more aggressive quantization, shorter context windows, lower decoding budgets, or stricter truncation policies. This is often referred to as “model degradation” or “model downgrade.”
3. Distillation impersonation: using a substitute model trained on large amounts of interaction data to directly replace the original model in external service.

The key point is that the technical nature of these three behaviors is the same: the caller cannot verify which weights, which parameters, and which context length actually produced a given output.

Traditional verification methods almost all fail. The self-reported model field is filled in by the service provider and can be forged arbitrarily. Response latency, token counts, and JSON structure can all be imitated. Prompt-injection-style questions such as “Are you GPT or some specific model?” can only elicit a politely trained response, which does not constitute any meaningful evidence.

2. Why proving that an output was generated by a specific model is difficult

Before designing a solution, it is necessary to recognize three objective obstacles. Otherwise, it is easy to build a system that looks rigorous but is actually ineffective.

First, the sampling process is inherently stochastic. When temperature > 0, the same input can produce different outputs at different times, making pure text comparison ineffective. Even setting the temperature to 0 does not eliminate all problems.

Second, floating-point computation does not guarantee bit-for-bit reproducibility. On GPUs, the order of parallel reductions, the kernel selected for matrix multiplication, and the padding length of requests in the same batch can all introduce tiny deviations in logprobs. These deviations usually do not change the result under greedy decoding, but they can cause divergence when multiple tokens have close argmax values. In long-text generation, the probability of divergence accumulates quickly. Therefore, the strong assumption that “deterministic replay produces character-for-character identical output” often does not hold in engineering practice.

Third, information asymmetry is structural. The service provider holds the weights, random seeds, KV cache, and complete sampling distribution. The caller only receives a piece of text. Any “guess after the fact” method can only provide a probabilistic conclusion.

The conclusion is clear: to obtain strong guarantees, the service provider must actively produce verifiable evidence during inference; to obtain weaker guarantees without changing the service side, statistical fingerprinting is the only practical route.

3. Path one: verifiable receipts (the cryptographic route)

This is currently the most reliable approach. The core idea is to replace “trust in the service provider’s verbal claims” with “verification of a signature that only the holder of a private key could have generated.”

3.1 A four-part protocol skeleton

(1) Challenge issuance. The caller generates a random nonce and sends it with the request. The service provider must include this nonce in the signed content. This step eliminates replay attacks. Otherwise, an attacker could record a genuine response and repeatedly deliver it to different customers.

(2) Deterministic inference commitment. The service provider declares the parameter fingerprint used for the inference: the model identifier and weight-version digest, decoding parameters, random seed, context-truncation policy, and quantization precision. These fields enter the signed payload. If a later audit finds that the actual behavior does not match the declared values, the receipt itself becomes evidence of a breach.

(3) Output commitment and signature. The normalized output token sequence is hashed, and this hash is signed together with metadata using the service provider’s private key. The signed receipt is returned with the response.

(4) Public verification. Any third party that holds the public key can verify the receipt independently without trusting intermediate links. This is the key value of the design: verification authority shifts from the service provider to the public.

A simplified receipt structure is shown below:

{
  "request_id": "b7f2c1...",
  "challenge": "b3a9...e71",
  "model_id": "chat-large-v3",
  "weights_digest": "sha256:9f2c...",
  "params": { "temperature": 0.0, "top_p": 1.0, "seed": 42, "max_tokens": 1024 },
  "context_policy": { "window": 131072, "truncation": "head+tail" },
  "quantization": "bf16",
  "usage": { "input_tokens": 812, "output_tokens": 233 },
  "output_hash": "sha256:4d1e...",
  "issued_at": "2026-08-26T20:41:22Z",
  "policy_version": "2026-03",
  "signature": { "alg": "Ed25519", "kid": "k-2026-03", "value": "<base64>" }
}

Example verification logic:

def verify_receipt(receipt, public_keys, expected_challenge, replay_cache):
    # 1) Replay protection: the challenge value must match the nonce issued by the caller for this request
    assert receipt["challenge"] == expected_challenge, "Challenge mismatch; possible replay or forgery"
    assert not replay_cache.seen(receipt["request_id"]), "request_id already used"
    # 2) Signature verification: serialize the canonical payload deterministically to avoid hash drift caused by whitespace differences
    payload = canonical_json({k: v for k, v in receipt.items() if k != "signature"})
    key = public_keys[receipt["signature"]["kid"]]      # from the pre-published public key set
    assert ed25519_verify(key, payload, receipt["signature"]["value"]), "Invalid signature"
    replay_cache.mark(receipt["request_id"])
    return receipt["model_id"], receipt["weights_digest"]

Three engineering details are easy to overlook:

• Canonical serialization must fix field order and numeric formats; otherwise, signature verification may fail randomly.
• Public keys need a kid mechanism plus rotation and revocation procedures; otherwise, there is no way to limit damage after a key leak.
• Cached request_id values need an expiration window to balance security and storage cost.

3.2 Zero-knowledge proofs: keeping receipts from exposing business data

The scheme above requires the service provider to disclose the model identifier and parameters. For vendors, this may be a commercial secret; for callers, it may create prompt-leakage risk. A further approach is proof generation in the direction of zero-knowledge machine learning, or zkML: the prover can demonstrate that an output was indeed produced by committed weights according to a declared computational graph, without disclosing the weights or inputs to the verifier.

The current status should be described objectively. Producing a complete inference proof for a general-purpose Transformer remains expensive. Main research directions include constructing arithmetic circuits after quantization to fixed-point numbers, using lookup arguments to handle nonlinear activations, and performing chunked recursive proofs for attention. Today, this approach is more suitable for small models, short sequences, or critical audit sampling scenarios. It is not yet economical to generate proofs for every online request.

A practical engineering compromise is sampling proofs plus full-coverage signatures: every request receives a signed receipt, while a certain proportion of high-risk calls also receive stronger proofs.

4. Path two: behavioral fingerprinting and statistical inspection (zero-integration route)

When the service provider does not cooperate, detection is still possible, but the conclusions can only be probabilistic. The core idea is that behavioral distribution differences among models in fine-grained details are often much more obvious than differences in standard question answering, and they are difficult to disguise without losing capability.

Stable fingerprint dimensions that can be collected include:

• Tokenizer boundary behavior: ask the model to repeat or count strings containing rare characters, emoji, consecutive spaces, or code indentation. Different tokenizers will expose differences in digit counts, space attribution, and segmentation behavior.
• First-token distribution: compare the next token for the same prefix under temperature 0. If logprobs are available, compare the distribution shape directly. If not, use repeated sampling to estimate the empirical distribution of the first token.
• Refusal and safety-policy fingerprints: construct a set of boundary-case prompts and measure refusal phrasing templates, rewriting strategies, and refusal-rate distributions.
• Formatting preferences: whether the model tends to use Markdown headings, list density, code-block language annotations, and summary-style endings.
• Boundary-capability inflection points: truncation behavior when the context approaches its limit, repetition degradation patterns in very long outputs, and handling of special tokens. Degraded deployments, such as aggressive quantization or shortened context windows, often reveal themselves first at these inflection points.

The judgment should use distribution distance and hypothesis testing, rather than character-by-character comparison:

import math
from collections import Counter
def empirical_dist(responses, extract_first_token):
    c = Counter(extract_first_token(r) for r in responses)
    n = sum(c.values())
    return {k: v / n for k, v in c.items()}
def kl_divergence(p, q, eps=1e-9):
    keys = set(p) | set(q)
    denom = 1.0 + eps * len(keys)          # smoothing prevents divergence caused by zero-probability terms
    total = 0.0
    for k in keys:
        pk = (p.get(k, 0.0) + eps) / denom
        qk = (q.get(k, 0.0) + eps) / denom
        total += pk * math.log(pk / qk)
    return total
# The baseline is collected from endpoints confirmed to be official direct connections during controlled periods.
# The probe set is fixed and versioned.
drift = kl_divergence(empirical_dist(probe_samples, first_tok),
                      baseline_first_tok_dist)
alert = drift > baseline_threshold_p99   # thresholds are derived from repeated baseline experiments

Engineering considerations:

• The baseline must be collected under controlled conditions, with a fixed probe set and fixed decoding parameters. It should be rebuilt whenever the official model version changes.
• The probe set should be version-controlled to avoid targeted adaptation by the upstream service provider.
• A single result is not sufficient for judgment. Multiple rounds of sampling should be performed, thresholds should be based on quantiles, and false-positive rates should be explicitly incorporated into alerting policies.

5. Integrating receipts into infrastructure: audit and inspection systems

Receipts and fingerprints are only meaningful when they are incorporated into daily operational workflows. The following categories are described generically and are not tied to any specific interface.

Logging service: persist request_id, model identifier, parameters, receipts, latency, and token usage in structured form. This creates a complete call chain from business requests to receipts and supports retrospective analysis by tenant, model, and time range.

Object storage: receipts and raw response bodies need long-term archival, usually aligned with the contract audit cycle. Immutable storage policies should be used to prevent post-hoc tampering. Store the original bytes, not merely the hash digest, so that evidence can be produced during disputes.

Message queue plus stream or batch computing: probe requests and inspection results can be processed asynchronously. Scheduled jobs can compare distribution drift, calculate KL divergence, and generate daily or weekly reports. Anomalous samples can be placed into a separate queue for manual review.

Monitoring and alerting: in addition to common metrics such as success rate, P99 latency, and rate-limit hit rate, three specialized metrics should be added: receipt-verification failure rate, anomalies in public-key or kid rotation, and model-fingerprint drift scores. A sudden increase in any of these usually indicates an unannounced upstream change.

Key-management service: hosting, rotation, and revocation of the public-key set used for signature verification should be handled through key-management and access-control systems. Least privilege should be enforced, and the private-key side should never be embedded in application code repositories.

Data security and compliance: probe sets and baseline data may indirectly reflect business characteristics and should be encrypted according to data classification. Challenge values and hashes in receipts are not reversible, but raw response bodies are sensitive data. Archival policies should align with retention and compliance requirements.

6. Practical recommendations for different roles

For model callers, such as enterprise application developers: model identity should be written into technical contracts, not merely procurement contracts. Require service providers to supply receipt fields that can be verified offline, publish public keys and rotation policies, and allow third-party sampling review. On the caller’s side, build a probe-baseline library and make drift detection a routine inspection. If applications run on Baidu AI Cloud, the audit loop can reuse general cloud capabilities such as logging, monitoring and alerting, object storage, and key management, rather than building the full storage and scheduling stack from scratch.

For model service providers: verifiable receipts essentially turn SLAs from mere promises into something that can be proven with evidence. For high-value customers, this is a differentiating capability. It also helps providers diagnose issues internally, because parameter fingerprints in receipts can quickly identify which configuration change caused a quality regression.

For the broader industry ecosystem: the metadata format for receipts should be as neutral and extensible as possible. Otherwise, vendors may create fragmented private formats, forcing callers to maintain separate verification logic for every upstream provider. Without interoperability, the approach risks degenerating into operational overhead.

7. Capability boundaries and risk warnings

It is important to be clear about what this approach proves and what it does not prove:

• A receipt proves that “this output was produced by the party holding the private key, in the declared manner.” It does not prove output quality. A service provider can truthfully sign a model that has actually become weaker.
• If the private key is leaked or the service provider itself is compromised, the validity of receipts drops to zero. Therefore, key custody and revocation mechanisms are as important as the cryptographic scheme itself.
• Identifying distillation is essentially a contractual and compliance issue. The role of technology is to provide an admissible evidence chain, not to deliver a direct conclusion.
• Deterministic inference and full receipt generation introduce additional overhead, including disabling some batching optimizations, serializing and signing payloads, and writing logs. They should be enabled in tiers according to business value, for example only for high-value or high-risk calls.
• The zero-knowledge proof route is still in the early stage of engineering maturity. Architectural designs should not assume that it can support full online traffic today.

8. Practical checklist

1. Define the threat model: preventing substitution, degradation, and distillation requires different verification strengths.
2. Prioritize challenge-response plus signed receipts. This is the step with the highest return on investment.
3. Build zero-integration behavioral-fingerprint inspection in parallel as a fallback when the upstream service does not cooperate.
4. Put receipts, baselines, and probe sets under version control, and rebuild baselines as upstream models evolve.
5. Establish key-rotation and revocation plans, and include receipt-verification failure rates in routine monitoring.
6. Align technical solutions with procurement and compliance requirements, and clarify audit rights and sampling-review mechanisms.

Competition in LLM services is shifting from “parameters and leaderboards” toward “verifiable deterministic delivery.” When outputs can be signed, audited, and independently verified by third parties, the arbitrage space created by information asymmetry will be truly reduced. This is both a defensive tool for callers and foundational infrastructure for service providers to build trust.