How to Verify LLM Responses: From Source Commitment to Cryptographic Proofs

After the rapid popularization of Large Language Model (LLM) services, users typically judge which model they are calling only through API endpoints, model names, and returned content. On the surface, a service provider may return the name of a high-specification model, but the actual request might be routed to a cheaper model, or even undergo secondary rewriting, capability cropping, or extra prompt injection.

The core of this problem is not “does the response look like it,” but a more fundamental identity authentication issue:

Can users use verifiable evidence to confirm that a response was indeed generated by a specified model?

In the past, many detection methods relied on empirical judgment. For example, asking the model a set of fixed questions to observe language style, reasoning ability, and output format; or checking API response fields, context length, and thought processes. These methods can serve as auxiliary analysis but rarely constitute strict evidence. This is because service providers can modify prompts, proxy layers can rewrite responses, and the model itself might change its style due to version updates.

Therefore, the industry is exploring a more reliable direction: adding “source proof” to model outputs, converting trust-based service relationships into independently verifiable technical facts.

I. Why LLM Responses Are Easily Spoofed

A typical LLM invocation chain usually involves four roles:

1. User or enterprise application;
2. API gateway or proxy service;
3. Actual model service;
4. Response and logging system.

When users directly access the API provided by the model vendor, the trust relationship is relatively simple. However, if a proxy layer is added in between, users often cannot observe where the request is ultimately routed.

For example, a proxy service might externally claim to provide a high-capability model, but internally it may reduce costs in the following ways:

• Routing some requests to models with smaller parameter scales;
• Dynamically switching models based on request types;
• Using fallback models during peak hours;
• Truncating input to reduce context costs;
• Rewriting, compressing, or filtering output;
• Using a combination of multiple models to generate the final answer.

From the user’s perspective, what they ultimately receive is still just a piece of text. Relying solely on the text itself makes it difficult to prove its true origin.

What makes this more complex is that models can be instructed to “introduce themselves.” As long as “You are a certain high-specification model” is written in the system prompt, many models will answer accordingly. Therefore, asking “Who are you?” does not constitute identity authentication; response style is also not a reliable proof of identity.

II. Core Idea: Letting Model Outputs Carry Verifiable Credentials

A universal solution is for the model service provider to generate a cryptographic proof for each output. The entire process can be abstracted into three stages: Commitment, Generation, and Verification.

1. The Service Provider Establishes an Identity Commitment

The model service provider first possesses a set of keys:

• Private key: securely stored only by the service provider;
• Public key: can be publicly distributed to users or verification systems.

The provider also needs to establish a clear identifier for the model’s identity, such as model name, version, configuration scope, and effective time. It is important to note that the model identity should not just be an easily modifiable string, but should be included in the signed data.

The provider can normalize and encode the following information:

Model Identifier
Model Version
Request Identifier
Input Digest
Output Digest
Timestamp
Nonce or Sequence Number

Then, use the private key to sign the encoded content, forming a “source commitment.”

The key here is not to expose the full conversation, but to compute digests of the input and output. Digests typically have the following characteristics:

• If the original content changes, the digest changes;
• The full original text cannot be reverse-engineered from the digest;
• The same content under the same rules yields a consistent result;
• It is suitable for inclusion in signatures and audit logs.

2. Generate Response and Bind Context

After the model completes inference, the server should not only sign the final text but should also bind the response to the request context as much as possible.

For example, the proof content can include:

{
  "model": "target-model",
  "request_digest": "Input Digest",
  "response_digest": "Output Digest",
  "issued_at": "Issuance Time",
  "nonce": "Nonce",
  "signature": "Digital Signature"
}

Here, request_digest is used to prove which request this response corresponds to, response_digest proves which output the signature covers, and nonce prevents old proofs from being reused.

If only the model name is signed without the response content, a proxy service could still take a genuine proof and pair it with a forged text. Therefore, the proof must simultaneously bind the model identity, request, and response.

3. User-Side Independent Verification

Upon receiving the response, the user can complete the verification using the public public key. The basic process is as follows:

Read the response text and proof information
Recompute the input digest according to agreed rules
Recompute the output digest according to agreed rules
Rebuild the payload to be verified
Verify the digital signature using the public key
Check the timestamp and nonce
Confirm if the model identifier meets expectations

The pseudocode can be represented as:

requestDigest  = hash(normalize(request))
responseDigest = hash(normalize(response))
payload = encode(
    modelId,
    requestDigest,
    responseDigest,
    issuedAt,
    nonce
)
valid = verify(publicKey, payload, signature)
if valid and modelId == expectedModel and nonceNotUsed(nonce):
    return "Source proof is valid"
else:
    return "Source cannot be confirmed"

Successful verification means: the party holding the corresponding private key did indeed sign this set of model identifier, request digest, and response digest.

III. What Practical Problems It Solves

1. Identifying Model Spoofing

If a proxy service claims to provide a high-specification model but cannot provide a corresponding valid proof, the user can at least confirm: this invocation did not receive a verifiable official source credential.

This is more reliable than observing text style because even if a proxy service can mimic the output style, it cannot generate a legitimate signature without the private key.

2. Detecting Tampered Responses

If the response is modified by the proxy layer after it is returned by the model service, even if only a single punctuation mark is changed, the recalculated output digest will differ, and the original signature will fail verification.

This can help detect:

• Output being rewritten secondarily;
• Sensitive content being automatically replaced;
• Partial paragraphs being truncated;
• The service provider summarizing or rearranging results.

3. Assisting in Tracking Capability Downgrades

If the service provider uses different models for different users, the proof can further bind the model version or configuration identifier. Users can use this to determine whether the current invocation falls within the agreed model range.

However, the proof can only indicate “what the service provider declared and signed,” and cannot independently prove that the model’s capability necessarily matches its marketing. The relationship between model version names, configuration fields, and actual capabilities still needs to be constrained by evaluations, audits, and service agreements.

4. Improving Enterprise-Level Auditing

For enterprise applications, model invocations usually involve compliance, data security, and accountability tracking. By saving request digests, response digests, proof information, and verification results, enterprises can establish a clearer audit chain.

For example, in the event of a business dispute, it can be confirmed:

• Which model version processed the request;
• Whether the response was modified during transmission;
• Whether the request came from an authorized server;
• Whether the proof is within the valid time range;
• Whether the same response was reused.

IV. Technical Boundaries That Cannot Be Ignored

Source proof is not a universal “anti-counterfeit label”; it relies on several prerequisites.

1. Requires Model Service Provider Cooperation

If the actual model provider does not issue proofs, third parties cannot prove out of thin air which model a piece of text came from. Content signed by a proxy service itself can only prove that “the proxy service claims this was generated by a certain model,” and cannot replace the model vendor’s identity commitment.

2. Private Key Security Determines Proof Credibility

Once a private key is leaked, attackers can forge legitimate signatures. Therefore, service providers need mechanisms such as Hardware Security Modules (HSMs), key rotation, access isolation, and anomaly monitoring.

Public keys also cannot be arbitrarily replaced by proxy services. Verification clients should obtain public keys through trusted channels and verify the public key’s fingerprint, version, and effective time; otherwise, attackers might pass off their own public keys as official ones.

3. Proof Does Not Equal Capability Guarantee

A signature can prove “who signed this content,” but cannot directly prove:

• The model response is definitely correct;
• The model did not hallucinate;
• The service provider did not use opaque routing strategies;
• The model’s internals were not updated;
• The training data or inference process fully met expectations.

Therefore, source proofs should be used in conjunction with model evaluations, version management, Service Level Agreements (SLAs), and log audits.

4. Privacy Issues Require Additional Design

If the signed content directly includes the raw input and output, it may cause sensitive data leakage. A more reasonable approach is to sign digests, keep the full raw text only internally within the enterprise, and manage associations through access controls.

For cross-organization verification, technologies such as Zero-Knowledge Proofs (ZKPs), verifiable logs, or third-party timestamps can be considered to minimize unnecessary information exposure.

V. How Proxy Services Should Implement This

If a proxy platform wishes to provide an auditable model invocation service, it is recommended to establish the following mechanisms:

1. Explicitly display the actual model source and version range;
2. Generate a unique request ID for each request;
3. Compute digests for input, output, and key metadata;
4. Use a protected private key to generate proofs;
5. Return the proof alongside the response;
6. Provide independent public keys and verification rules;
7. Maintain tamper-proof invocation logs;
8. Record model switching, version updates, and failure downgrades.

The verification end should avoid simply displaying “Verification Successful,” but should further display:

• The issuing entity;
• The model identifier;
• The proof generation time;
• Whether the request and response match;
• Whether the public key is within its validity period;
• Whether there is reuse or a clock anomaly.

VI. How Regular Users Should Judge Service Trustworthiness

Before relevant standards become widespread, users can adopt a layered judgment strategy:

First, check whether the service explicitly discloses the actual model, version, and routing rules;
Second, confirm whether the returned result contains verifiable source credentials;
Third, check whether the credentials are verified by a trusted public key, rather than just being self-displayed on the service provider’s webpage;
Fourth, use multi-round evaluations and cross-verification for critical business tasks;
Fifth, do not treat model self-introductions, language styles, or single test results as identity credentials.

For scenarios involving code, finance, medical care, or enterprise secrets, users should also focus on whether data is forwarded through third parties, how long logs are retained, and whether the proxy service modifies requests and responses.

Conclusion

Competition among LLM services is gradually extending from “can it generate a response” to “can it prove where the response came from.” Source proofs based on digital signatures, digests, and key verification provide a universal path for addressing model spoofing, response tampering, and service downgrades.

It cannot replace model evaluations, nor can it guarantee that responses are absolutely correct, but it can transform model identity—which previously could only rely on verbal commitments—into verifiable, auditable technical evidence.

For service providers, this is the infrastructure for improving transparency and building trust; for users and enterprises, it is an important tool for identifying false model marketing and reducing invocation risks. In the future, as verification protocols gradually standardize, “identity authentication” for model invocations may become a routine part of intelligent application infrastructure, much like web certificates.