Verifiable AI Responses: How Model Attestation Detects Proxying and Model Downgrades

In the rapid adoption of generative AI services, users typically see only the final text, not the real invocation path behind an answer. An API may claim to provide a high-capability model while actually forwarding requests to a lower-cost model. A provider may also switch models during peak periods, limit inference budgets, or use a distilled or modified substitute model. For ordinary users, the answer content itself is often insufficient to prove model identity.

The core problem is the lack of a verifiable connection between a service promise and the technical reality. In the past, users relied on answer style, knowledge level, context handling, and API response fields, but these methods all have clear limitations. A more reliable approach is for the model service provider to attach a independently verifiable cryptographic proof to each answer, turning “I did use a certain model” from a verbal claim into a technical credential that can be checked.

1. Why Answer Content Alone Cannot Identify a Model

Many users try to ask the model directly: “What model are you?” However, this only produces a textual claim and cannot serve as trustworthy evidence. As long as the server adds identity instructions to the prompt, almost any model can output the same answer.

Even without prompt-based disguise, a single answer is difficult to use for model identification. There are three main reasons.

First, different models may perform very similarly on common tasks. For simple Q&A, format conversion, or routine code generation, multiple models can produce seemingly reasonable results.

Second, providers can post-process outputs. For example, they may modify system prompts, add post-processing rules, filter content, or even wrap one model’s answer in another model’s response format.

Third, model behavior is inherently stochastic. The same model can produce very different results under different temperatures, context lengths, inference budgets, and system configurations. Therefore, a single test showing that a model is “smart” or “slow” cannot directly determine model identity.

As a result, style analysis, fixed-question tests, and field inspection can provide probabilistic judgments at best. They cannot answer the central question: was this answer actually generated by the declared model?

2. Basic Principles of Model Response Attestation

Model response attestation can be understood as a digital signature mechanism for generated results. After the model completes an answer, the service provider generates a proof based on the request, model identifier, key runtime context, and output content, then signs it with a private key held only by the official server.

After receiving the answer, a verifier can use public verification information to check:

1. Whether the proof was issued by a trusted model service provider;
2. Whether the proof exactly matches the current request and answer content;
3. Whether the model identifier declared in the proof falls within the specified scope;
4. Whether the proof was generated within its valid time window;
5. Whether the proof has been tampered with, copied, or reused.

A simplified data structure can be represented as:

attestation_payload =
{
  request_digest: digest of the request,
  response_digest: digest of the response,
  model_identity: model identity identifier,
  policy_digest: digest of the runtime policy,
  issued_at: issuance time,
  nonce: random number
}
signature = Sign(private_key, attestation_payload)

Digests are usually generated with hash algorithms. The verifier does not necessarily need to see all sensitive content in the original request. As long as it can recompute the digest and compare it with the value in the proof, it can determine whether the proof corresponds to the current answer.

The key value of this approach is that a proxying service can forward text, but it cannot easily forge a valid proof signed by the official private key. If it calls a low-cost model, the digest corresponding to the answer cannot simultaneously match a valid signature from the target model.

3. How a Complete Verification Flow Works

A relatively complete flow usually includes the following stages.

1. Client Submits a Request

The user submits a question to the service entry point with the necessary session information. To prevent intermediaries from replacing the request, the client can generate a unique random number for the request or include an incrementing sequence number and time window.

2. Official Server Executes the Model

The server selects a specific model based on authorization information, processes system instructions, user input, and context, and generates the final answer. At this point, the model server should record the minimum necessary metadata related to the invocation, such as the model version identifier, policy digest, and request trace number.

3. Server Generates the Response Attestation

After the answer is complete, the server signs the request digest and response digest. The signed content should not contain only the model name, because the name itself can be forged. It should bind the specific request and the specific output.

4. Return the Answer and Attestation

The API returns both the text and the attestation information. The attestation can be transmitted in a structured format or encapsulated in protocol headers or a separate field. Even if a proxying service modifies the answer, it will break the correspondence between the response digest and the signature.

5. User or Audit System Performs Verification

The verifier obtains the public key or a trusted key list, recomputes the request and response digests, and then checks the signature, time, nonce, and model identifier. Successful verification indicates that the answer at least satisfies the condition of being issued by a trusted server and not having been tampered with.

Note that verification does not necessarily require users to upload the full conversation to a third party. Through local verification, selective disclosure, and zero-knowledge proofs, some authenticity checks can be performed while protecting privacy.

4. What Attestation Can Solve

1. Detecting Model Substitution

If a provider claims to offer a high-capability model but actually forwards requests to a low-cost model, it cannot generate a matching valid credential unless it can obtain a proof issued by the target model provider.

2. Detecting Secondary Modification of Answers

Some services may trim, replace, or insert marketing content into answers. Because the response digest changes, the original signature will generally no longer pass verification.

3. Supporting Enterprise Audits

Enterprises can link model attestations with business logs, ticket records, and data access records to form a more complete audit chain. In finance, healthcare, government, and R&D scenarios, this helps trace the source of key conclusions.

4. Improving Dispute Resolution for Service Quality

When users believe service quality has declined, the model identifier, policy digest, and time information recorded in the attestation can help determine whether the issue comes from model switching, parameter changes, prompt modifications, or business-side post-processing.

5. What It Does Not Solve

Attestation is valuable, but it should not be understood as a “model quality proof” or “answer correctness proof.”

First, a signature can only prove that a trusted server issued an answer. It cannot prove that the answer content is correct. Models can still produce factual errors, logical errors, or incomplete conclusions.

Second, the credibility of the proof depends on the issuer. If the provider’s internal records are inaccurate or the signing logic itself is opaque, external verification still has boundaries.

Third, model identifiers need to be sufficiently detailed. If a proof only says “general large model,” it cannot confirm the specific version, runtime configuration, or capability level. A better design should specify the version scope, policy digest, and invocation time while avoiding disclosure of internal implementation details.

In addition, an attacker might obtain a legitimate proof by “calling the real model first, then modifying the prompt context.” Therefore, the attestation system should bind the full request digest, system policy digest, and session state as much as possible, rather than signing only the final text.

6. How Proxying Services Should Design a Trusted Chain

For providers that offer model aggregation, the safer approach is not to claim model identity on their own, but to preserve upstream attestations and pass them transparently downstream. A well-defined chain should include at least:

• The original attestation issued by the upstream model provider;
• The proxying service’s own forwarding records;
• The correlation ID between request and response;
• Whether content filtering, format conversion, or secondary generation occurred;
• Records of failed retries and model downgrades.

If a proxying service regenerates an answer, it should not continue to use the original model’s attestation. Instead, it should clearly mark the result as “post-processed” or “regenerated.” This is more consistent with auditability than simply disguising the result as an original answer.

When procuring model services, enterprises can also include attestation verification in acceptance criteria and require providers to offer a public verification mechanism, key rotation documentation, proof field definitions, and exception-handling policies.

7. Implementation Considerations for Developers

At the implementation level, the following issues deserve attention:

1. Anti-replay: Add a random number, timestamp, or unique sequence to each request so that old proofs cannot be copied to new requests.
2. Privacy protection: Prefer signing digests rather than directly exposing original prompts and full context.
3. Key governance: Establish key rotation, revocation, and version management mechanisms so that verifiers do not trust expired keys indefinitely.
4. Explicit states: Distinguish among “verification succeeded,” “proof missing,” “invalid signature,” “content modified,” and “model identity mismatch.”
5. Evidence logging: Write verification results, proof versions, and time information into audit logs that cannot be arbitrarily modified.
6. Avoid overpromising: Successful verification only shows that source and integrity comply with the rules. It cannot replace factual verification or human review.

8. Future Directions

As model invocation chains become more complex, verifying only the final text may not be enough. Future attestation systems may further cover tool calls, retrieval sources, code execution, data versions, and security policies, forming layered proofs from input and reasoning to output.

However, fully disclosing internal reasoning processes would create privacy, security, and intellectual property risks. A more realistic direction is to provide attestation mechanisms that are “verifiable but not fully public”: verifiers can confirm key facts without obtaining internal model secrets.

Overall, model response attestation will not automatically make AI more accurate, but it can significantly reduce the trust costs caused by identity impersonation, model substitution, and output tampering. For users, it provides a more reliable basis for judgment than “asking the model to identify itself.” For enterprises, it establishes auditable invocation credentials. For service providers, it also pushes model aggregation businesses from verbal promises toward verifiable technical responsibility. A truly mature AI service should not only answer well, but also be able to explain where the answer came from, what processing it underwent, and why users should trust it.