AI Response Anti-Fraud: Signing Model Outputs to Prove Authenticity

1. Why AI Responses Need Anti-Fraud Marks

People who use API relay or proxy services often encounter a confusing situation: two services may advertise the same flagship model, but one responds like an expert while the other produces inconsistent or low-quality answers. In some cases, the explanation is simple: the request is labeled as a flagship model, but the actual execution is handled by a cheaper model.

Relay services have a direct incentive to create this gap. Every reduction in cost increases margin, and the motivation to substitute, downgrade, or otherwise manipulate model usage is already present.

Three common “bait-and-switch” techniques

1. Full substitution: The request is forwarded to a smaller and cheaper model, and the response is returned unchanged. Billing remains based on the flagship model, while the service provider keeps the price difference.
2. Runtime downgrade: The upstream endpoint may indeed be official, but the service provider silently reduces capability through parameters. Examples include limiting the reasoning budget, lowering sampling temperature, shortening the context length, reducing tool calls, or modifying the system prompt. Response quality drops, but the bill does not.
3. Distillation-based impersonation: Outputs from one model are used as training data for a smaller “student” model, which is then served as if it were the original model. Model distillation itself is a legitimate compression technique. The problem arises when a distilled model impersonates the original model and charges for it as such.

Why asking “Who are you?” does not work

A large language model’s output is fundamentally a probability-based sampling result under a given context. Its supposed “identity” is a pattern in training data, not a measurable physical property. If a relay service adds a system prompt saying, “You are a certain flagship model,” the model will usually repeat that claim. Conversely, if the model says it is a smaller open-source model, that does not prove anything either.

Self-reported identity can show what the model was prompted to say. It cannot prove what actually generated the response.

How far existing detection methods can go

Common community methods include comparing response style, checking returned fields, and verifying signatures on reasoning traces. Each has clear limitations:

• Style comparison is unreliable. Sampling introduces randomness, so the same model may phrase answers differently across runs. At the same time, carefully designed prompts can make a smaller model imitate a particular style.
• Response field checks only show that a response passed through some upstream component. Fields and metadata themselves can be fabricated.
• Reasoning-signature checks usually verify whether the reasoning content was modified. They may not cover the full request context and often cannot distinguish specific model versions. They prove that the output came from a vendor, but not necessarily from the exact version that was paid for.

More importantly, these methods produce inferences, not proof. Model vendors themselves often struggle to respond to “degraded intelligence” complaints. Even when the model has not changed, they may lack credible evidence to demonstrate their innocence.

Ultimately, the authenticity of AI responses has relied on trust. Replacing trust with proof requires a credential that only the true generator can create and that anyone can independently verify. This is the core problem that an authenticity proof must solve.

2. How an Anti-Fraud Proof Works

2.1 Core idea: from trust to proof

In cryptography, digital signatures address a classic problem: how can a receiver confirm that a message truly comes from the claimed sender and has not been altered in transit?

The mechanism can be summarized in three points:

• The signer uses a private key held only by itself to generate a signature value for the message.
• Anyone can use the corresponding public key to verify the signature.
• Only the holder of the private key can produce a valid signature, and changing even one bit of the signed content will cause verification to fail.

When this mechanism is applied to model services, the model provider acts as the issuer. It signs generated responses with a private key, effectively stamping the response with an authenticity mark. An impersonator without the private key cannot forge a valid stamp for a swapped response.

2.2 What a complete anti-fraud proof contains

A simplified structure is shown below. It is for illustration only and does not represent any specific API interface.

{
  "text": "...model-generated response...",
  "proof": {
    "key_id": "key-2026-03",
    "model_id": "flagship-chat",
    "model_version": "2026-03-01",
    "sampling_params": { "temperature": 1.0, "max_reasoning_tokens": null },
    "request_digest": "sha256:3f9a...",
    "response_digest": "sha256:c71e...",
    "timestamp": "2026-03-01T08:00:00Z",
    "nonce": "b41f...",
    "signature": "..."
  }
}

Each field serves a specific purpose:

• request_digest and response_digest: These are hashes of the normalized full request and full response. The full request includes the system prompt, conversation history, and tool outputs. Putting digests rather than raw content into the signature ensures that the content cannot be tampered with without increasing the signature size as content grows.
• key_id: This identifies the key used for signing. The client uses it to select the corresponding public key. Keys need periodic rotation, and this field allows old public keys to remain available for a period so that historical proofs can still be verified.
• model_id, model_version, and sampling_params: These answer the questions “Which model? Which version? With what parameters?” Only when this information is covered by the signature can the provider be held responsible for whether a flagship model was actually run with flagship-level configuration.
• timestamp and nonce: The timestamp indicates the freshness of the response. The nonce is a one-time random value generated by the caller. Together, they help prevent replay attacks, where a legitimate response from an expensive request is repeatedly reused as the result of other requests.

2.3 Why impersonators cannot forge it

To forge a proof that passes verification, an impersonator would need to do at least one of the following, and each option is impractical:

• Obtain the private key. The private key remains in the provider’s signing service. It is not delivered in API responses and is not handed to any intermediary.
• Copy an existing signature. The signature is bound to a specific request digest, response digest, and nonce. If the question, response, or nonce changes, verification fails.
• Modify fields in the proof. Information such as model version and sampling parameters is covered by the signature. Any modification also causes verification to fail.

There is one point that is easy to misunderstand: an authenticity proof does not prevent a request from being forwarded. It prevents a swapped response from being passed off as legitimate. A relay service can still forward requests and can receive genuine signatures. However, if it replaces the response with one generated by a cheaper model, it either cannot provide a valid signature or presents a signature whose model information does not match.

2.4 Example client-side verification code

The following is an illustrative verification flow. It is pseudocode and omits encoding and canonicalization details.

def verify_response(resp, keyring, expected_model_id):
    """
    Verify the authenticity proof of a single response.
    resp:     The response object returned by the call.
    keyring:  A public-key ring that retrieves keys by key_id
              and determines whether a key is still valid.
    """
    proof = resp.extensions.get("proof")
    if not proof:
        return "UNSIGNED"  # No proof; the source cannot be trusted.
    public_key = keyring.get(proof["key_id"])
    if public_key is None:
        return "UNKNOWN_KEY"
    payload = canonical_encode(  # See the canonicalization rules below.
        model_id=proof["model_id"],
        model_version=proof["model_version"],
        params=proof["sampling_params"],
        request_digest=proof["request_digest"],
        response_digest=proof["response_digest"],
        timestamp=proof["timestamp"],
        nonce=proof["nonce"],
    )
    # Verify the signature before performing business checks.
    if not verify_signature(public_key, payload, proof["signature"]):
        return "INVALID"
    if not keyring.is_active(proof["key_id"]):
        return "KEY_NOT_ACTIVE"
    if is_replayed(proof["nonce"]):
        return "REPLAYED"
    if not is_fresh(proof["timestamp"]):
        return "STALE"
    if proof["model_id"] != expected_model_id:
        return "MODEL_MISMATCH"
    # The request fingerprint must match the local record.
    # Otherwise, a valid signature from another request could be reused.
    if not request_log.matches(resp.request_id, proof["request_digest"]):
        return "REQUEST_MISMATCH"
    return "OK"

2.5 Engineering pitfalls

1. Canonical encoding: The same text can have multiple valid encodings, such as different whitespace, Unicode combining characters, or escape sequences. If the signer and verifier interpret encoding details differently, they may compute different digests, causing a valid signature to fail verification. The hashing rules must be strictly unified before implementation.
2. Timing of streaming responses: Most major model APIs return content incrementally in a streaming fashion, but a signature can only cover a complete response. A practical approach is to append a final message chunk containing the authenticity proof at the end of the stream. Until the client receives the end marker and completes verification, displayed content should be treated as “unconfirmed.”
3. Local request fingerprint: The caller should record the normalized digest of the full request when sending it, and compare it during verification. Otherwise, an attacker could attach a valid signature generated for question A to a response for question B.
4. High concurrency and batch scenarios: Verifying every response individually adds overhead. Costs can be reduced through public-key caching, batch verification interfaces, and asynchronous verification queues.
5. Key lifecycle management: Keys need regular rotation. Old public keys should remain usable for a reasonable period so that historical records can still be verified. Revocation status must also be supported. Without these measures, recovery options after a key leak are very limited.

3. Why Anti-Fraud Proofs Have Not Become Standard

The principle is not complex, and the engineering implementation is not especially difficult. So why has this capability not become a standard feature of model services?

The main reasons are cost and tradeoffs, not technical impossibility.

1. Performance overhead: Every generation requires two hash computations and one signature operation. The cost per request may be small, but large model services process a high volume of requests. When combined with supporting infrastructure such as public-key distribution, revocation queries, and key rotation, the overall cost is not trivial.
2. Privacy concerns: A request digest is bound to the final response. Once a proof is made public, it effectively declares that “this response was generated by this platform, with this model version, at this time.” Vendors must carefully weigh whether they are willing to make such a public statement for every response.
3. Misuse as endorsement: A valid proof can be taken out of context. For example, someone may screenshot a fragment and label it “officially certified,” which could unintentionally lend credibility to misleading claims.
4. Forensic responsibility: The more rigorous the proof, the more likely it is to be used as evidence in disputes, such as service-quality complaints or regulatory checks on data flow. Platforms need corresponding mechanisms for evidence collection and response.
5. Transparency concerns: Once a signature reveals model version and generation parameters, adjustments to prompts and sampling parameters become observable. Excessive transparency may also enable version-by-version comparison and reverse inference of internal strategies.

A common misconception is that signatures prevent distillation. In fact, the two address different stages. Distillation occurs during training, while signatures operate during inference. Signatures can prevent an impersonating model from pretending to be the legitimate one, but they cannot stop someone from training their own model on legitimate outputs. Dealing with distillation more realistically requires service terms, account-behavior risk controls, rate limiting, and output-side detection such as style shifts or subtle statistical markers. These techniques usually depend on model details and are more likely to be controlled by model vendors than by relay service providers.

4. What Anti-Fraud Proofs Can and Cannot Do

Scenario	Detectable?	Notes
A cheaper model impersonates a flagship model	Yes	There is no valid signature, or the model identifier in the signature does not match.
A distilled imitation model impersonates the original model	Yes	The impersonator cannot obtain the private key.
Offline forgery or reuse of old responses	Yes	The nonce and timestamp prevent old signatures from being reused.
A lower-cost tier from the same provider	Detectable, but hard to classify	The signature shows the lower-cost model. This is product design, not impersonation.
Runtime downgrade, such as a reduced reasoning budget	Depends on coverage	It can be detected if the relevant parameters are signed; otherwise, it cannot be determined.
Poor response quality or factual errors	No	The proof only guarantees that the response was generated by a specific version, not that it is high quality.
A valid signature used out of context	No	This is a usage problem and requires norms from both platforms and users.
Distillation during training	Not directly	Contractual, risk-control, and output-side detection methods are needed.

Two additional points are worth noting:

• Anti-fraud proofs are not universal, but they can complement orthogonal techniques. For example, output fingerprinting based on model-specific behavior can provide supporting evidence when there is suspicion but no certainty. Remote attestation from trusted execution environments can prove from a hardware perspective that code has not been tampered with.
• For ordinary users, practical judgment remains straightforward: be cautious about channels whose prices are far below a reasonable cost range. Asking the same question in different ways and running it multiple times often reveals quality fluctuations more clearly than any “official label.”

5. Conclusion

Model capabilities are becoming stronger, but the invocation chain is also becoming longer. A single request may pass through gateways, aggregation platforms, resellers, and other layers. Each layer has both the incentive and the opportunity to substitute or downgrade the service.

The value of an anti-fraud proof is that it shifts the question from “Do I trust this service provider?” to “Can I verify this response?”

It cannot guarantee that every response is correct, and it cannot prevent model capabilities from being distilled. But it makes the question “What did I actually buy?” verifiable for the first time. For enterprises purchasing AI capabilities, the key questions are whether providers are willing to issue verifiable proof of which model was used, and whether the enterprise can verify signatures, retain logs, and trigger alerts at the gateway layer. For developers, the important point is to understand the boundary: a signature can prove origin, but it cannot prove quality.