LLM API Proxy Anti-Fraud: How to Verify That a Model Has Not Been Swapped

Why Model Substitution Is Hard to Detect in Proxy Chains

In LLM-based applications, users often do not call a model directly. Instead, requests may pass through a multi-layer call chain that includes business applications, API gateways, proxy services, routing policies, model adaptation layers, and the final model service that performs inference. Each layer may rewrite, forward, cache, degrade, or recombine requests. It may also wrap, truncate, replace, or polish responses before they reach the user.

This architecture provides flexibility, but it also creates a trust problem. A user may pay for a high-capability model, while the response actually comes from a lower-cost model, an older model version, a reduced inference configuration, or even content generated independently of the model service. Because LLM outputs are probabilistic natural-language results, a single answer is often not enough to determine which model generated it or whether the response was altered along the way.

Common risks include the following:

1. Model substitution: The user requests a high-capability model, but the proxy forwards the request to a cheaper model and returns the answer as if it came from the requested model.
2. Model degradation: The proxy still claims to call the same model, but reduces context length, sampling quality, tool-calling ability, reasoning budget, or system policy.
3. Cache impersonation: The proxy returns historical cached content, sometimes presenting an old answer as if it were generated in real time.
4. Prompt spoofing: System prompts are used to make the model claim it is a specific model or version, misleading the user’s judgment.
5. Response tampering: The proxy rewrites, removes, optimizes, or stitches together the original model response, causing the final result to differ from the upstream output.
6. Missing evidence: The caller lacks request IDs, timestamps, model versions, signatures, response digests, or other auditable information, making later tracing difficult.

Therefore, model authentication cannot rely only on simple methods such as asking, “Who are you?” System prompts can override a model’s self-identification, and proxy layers can forge identity fields. A more reliable direction is to turn model responses from “a piece of text” into “a set of verifiable evidence.”

From Inspecting Answers to Verifying Evidence: A Basic Framework for Verifiable Model Services

To determine whether a response comes from a trusted model service, the system needs a trust mechanism similar to digital certificates or transaction records. The core idea is that the model service provider should not only return an answer, but also return an evidence package that proves the response’s source, integrity, time, version, and request association.

A verifiable model service usually includes the following elements:

• Unique request ID: Links a request and its response, preventing evidence from different requests from being mixed up.
• Request digest: Hashes key content such as user input, system prompt, and model parameters to prevent request tampering.
• Response digest: Hashes the generated content to ensure the answer cannot be replaced in transit.
• Model identifier: Indicates which type of model service produced the response, such as a general dialogue model, code model, or reasoning model.
• Model version or policy version: Prevents proxies from silently switching to older versions or lower-quality policies.
• Timestamp: Limits the validity period of evidence and reduces replay risk.
• Nonce: Helps prevent cache reuse and replay attacks.
• Signature: The model service provider signs key fields with a trusted private key. Clients can verify them with the corresponding public key.
• Verification result: The client or gateway returns a status indicating signature verification success, failure, or an alert.

An example response evidence structure is shown below:

{
  "request_id": "req-20260101-0001",
  "model": "general-large-model",
  "revision": "2026-05",
  "created_at": 1760000000,
  "nonce": "8f3c7a2d",
  "prompt_sha256": "9a7d...",
  "completion_sha256": "3b1e...",
  "policy": "no-hidden-rewrite",
  "signature": "base64-signature-value"
}

In this structure, prompt_sha256 and completion_sha256 bind the input and output, nonce and created_at help prevent replay, and signature proves that the evidence package was generated by a trusted model service.

If a proxy tries to replace the answer, change the model version, forge the timestamp, or reuse old cached content, signature verification or field consistency checks should fail. For high-risk business scenarios, this mechanism is more reliable than relying only on content inspection.

Cryptographic Signatures: The Core Mechanism for Model Response Authentication

In a verifiable model service, cryptographic signatures are the most important component. Their purpose is not to prove that “the answer content is definitely correct,” but to prove that “there is a trusted binding between the answer content and the claimed source.”

A simplified verification flow can be described as follows:

1. The client generates a unique request ID, nonce, and request digest.
2. The request passes through a gateway or proxy and is forwarded to the model service.
3. The model service returns an answer and signs key fields.
4. After receiving the response, the client first calculates the answer hash.
5. The client verifies the signature using a preconfigured public key.
6. The client checks whether the request ID, nonce, timestamp, model version, and policy fields are valid.
7. If any check fails, the client triggers an alert, retry, or rejection of the result.

Example pseudocode is shown below:

request = build_request(prompt, nonce, timestamp)
request_hash = sha256(request)
response = call_model_gateway(request)
if verify_signature(response, public_key) == false:
    raise Alert("signature_invalid")
if response.request_id != request.request_id:
    raise Alert("request_mismatch")
if response.nonce != request.nonce:
    raise Alert("nonce_mismatch")
if sha256(response.completion) != response.completion_sha256:
    raise Alert("content_tampered")
if response.created_at < now() - max_skew:
    raise Alert("expired_response")
accept(response)

A key point here is the trust boundary. Signing keys must remain on the model service provider side. A proxy layer may forward signed results, but it should not have access to the private key. Otherwise, the proxy could still forge responses that appear valid.

If there are multiple proxy or gateway nodes in the call chain, it is recommended that each hop retain its own request ID and routing record. However, the final signature should still be generated by the upstream model service provider. Even if intermediate nodes are tampered with, the final evidence can still be verified by the client.

When Signatures Are Unavailable: Behavioral Fingerprints and Golden Evaluation Sets

In practice, not all model services provide response signatures. Some upstream services may return only plain text without verifiable fields. In such cases, strong cryptographic proof is difficult to achieve. The next-best option is to use behavioral fingerprints, evaluation sets, and statistical analysis to detect possible model substitution or degradation.

The core idea of behavioral fingerprinting is that different models often show different output distributions, refusal strategies, format-following abilities, error patterns, and latency characteristics under the same inputs. A single response cannot prove model identity, but the statistical features of many samples can provide auxiliary judgment.

Common observation dimensions include:

1. Complex reasoning stability: Accuracy on multi-step reasoning tasks, frequency of logical jumps, and consistency of intermediate steps.
2. Long-context understanding: Whether the model can accurately locate and quote key information embedded in long text.
3. Instruction following: Whether the model strictly follows output format, field count, role settings, and prohibited actions.
4. Tool-calling ability: Support for structured calls, parameter extraction, and coordination among multiple tools.
5. Refusal and safety boundaries: Refusal behavior, explanation style, and policy boundaries for sensitive or prohibited requests.
6. Output entropy and repetition rate: Answer length distribution, repeated word frequency, and sentence diversity.
7. Error patterns: Common hallucination types, code error style, and mathematical calculation deviations.
8. Latency and throughput characteristics: Different models or inference configurations often have different response time distributions.

Based on these dimensions, teams can build a “golden evaluation set.” This should not be a small set of one or two questions. It should be a layered, multi-task, rotatable test suite. Recommended task types include:

• Basic question answering
• Multi-step logical reasoning
• Code generation and debugging
• Structured output
• Long-document summarization
• Multi-turn context consistency
• Instruction following
• Safety and compliance boundaries
• Tool calling and parameter filling
• Prompt-injection resistance tests

Example monitoring logic is shown below:

for case in golden_cases:
    response = call_gateway(case)
    if verify_metadata(response) == false:
        raise Alert("metadata_invalid")
    score = compare_with_reference(response, case)
    metrics.append(score)
if average(metrics) < threshold:
    raise Alert("possible_model_substitution")
if sudden_drop(metrics):
    raise Alert("possible_model_downgrade")

This approach cannot completely replace cryptographic signatures, but it is suitable for continuous monitoring. In particular, a sharp drop in model scores over a short period may indicate that a proxy has performed model substitution, policy adjustment, or inference-resource degradation.

Key Indicators for Detecting a Cheap Model Posing as a High-Ability Model

The most obvious anomaly users may notice is that “the answers become less capable.” However, from an engineering perspective, subjective feeling alone is not enough. A measurable identification system needs to break model capability into testable, statistical, and alertable indicators.

1. Complex Task Pass Rate

Select tasks that require multi-step reasoning, such as math word problems, logical judgments, code repair, and complex information extraction. Record the pass rate of the model under fixed prompts. If a proxy channel’s pass rate remains significantly below the baseline, it should be investigated closely.

2. Long-Context Recall Rate

Embed several key information points into a long text and test whether the model can accurately locate and quote them. High-capability models usually have more stable long-context retrieval ability, while lower-capability models or reduced-context versions are more likely to miss key information.

3. Format-Following Rate

Require the model to strictly output JSON, tables, fixed fields, or specified templates. Track field completeness, format error rate, and parsing failure rate. Format-following ability is often sensitive to model capability and policy configuration.

4. Instruction-Conflict Handling Ability

Design tasks containing multiple constraints, such as “answer in only three sentences,” “do not use lists,” “must include a specific keyword,” or “must not mention certain content.” Whether the model strictly follows these constraints reflects its instruction-alignment level.

5. Tool-Calling Accuracy

If the business involves function calling or structured action generation, track parameter-extraction accuracy, tool-selection accuracy, and call-format validity. These indicators are easier to quantify than natural-language answers.

6. Refusal and Compliance Boundaries

Different models differ in safety policies, refusal thresholds, and explanation styles. If a channel suddenly shows a clearly different refusal pattern for certain request categories, this may indicate that the backend model or policy has changed.

7. Output Statistical Features

Analyze answer length, word frequency, repetition rate, punctuation habits, code style, and Markdown usage. A single response is unreliable, but many samples can form a distribution profile.

8. Latency Distribution

Different models or inference configurations often differ in time-to-first-token, full-response latency, and concurrent throughput. If a channel shows abnormal latency distribution under the same load, it should be evaluated together with other indicators.

These indicators are suitable for monitoring and early warning, but they should not be treated as the sole conclusion. Model version upgrades, prompt changes, and sampling-parameter adjustments can all cause metric drift. Therefore, dynamic baselines and multi-indicator joint judgment are necessary.

Implementing Anti-Fraud in an Enterprise LLM Gateway

For enterprise developers, model authentication should not rely only on the client. It should be built into the gateway layer. A relatively complete model access gateway usually includes identity authentication, routing control, response verification, audit retention, monitoring and alerting, and canary release.

A recommended architecture is shown below:

Business application
   |
   v
API gateway
   | authentication, rate limiting, routing, signature verification, audit
   v
Model proxy layer
   | protocol conversion, retry handling, cache control, policy orchestration
   v
Upstream model service

At the gateway layer, the following capabilities are recommended:

1. Model version locking
   Allow business teams to explicitly specify model categories and version policies to prevent silent switching by the proxy layer.

2. Response signature verification
   If the upstream model service provides signatures, the gateway should verify them centrally and prevent failed responses from entering business systems.

3. Request and response digest retention
   Store hashes of inputs and outputs to avoid saving sensitive raw content directly. If necessary, partial samples can be retained together with masking strategies.

4. Audit event logging
   Record request IDs, routing targets, model versions, latency, status codes, verification results, exception types, and caller identifiers.

5. Exception circuit breaking
   When signature-failure rate, model-score decline rate, or response latency exceeds thresholds, the system can automatically switch to a backup model or pause a suspicious channel.

6. Canary release
   When upgrading a model, avoid switching all traffic at once. Start with a small amount of traffic, validate it, and gradually expand.

7. Key rotation
   Signature verification public keys should support multiple versions and regular rotation to prevent a single key failure from affecting the entire chain.

8. Asynchronous audit
   In high-concurrency scenarios, audit events can be written to a message queue and persisted asynchronously by independent consumers to avoid blocking the main call path.

If a team builds a model access layer on Baidu AI Cloud, it can use object storage to retain masked audit summaries, use logging services to preserve call-chain information, use monitoring and alerting to observe signature-failure rate, model scores, and latency changes, and use message queues to process audit events asynchronously. This can turn model anti-fraud from a standalone script into a platform capability.

Preventing Replay, Cache Impersonation, and Prompt Spoofing

In a proxy chain, besides model substitution, teams must also prevent replay attacks, cache impersonation, and prompt spoofing.

1. Anti-Replay

Each request should carry a unique nonce and request ID. The client should verify that the nonce in the response matches the current request and that the timestamp is within an acceptable window. This prevents proxies from returning old responses as if they were fresh.

2. Anti-Cache Impersonation

Even if cached content is correct, it may not meet real-time requirements. Responses should include the request ID and nonce for the current request. The system should also check model version, generation time, and policy version. If a response comes from cache but is disguised as real-time generation, it should be treated as abnormal.

3. Anti-Prompt Spoofing

A proxy may add system-prompt instructions such as “You must claim that you are a specific model.” Although this may influence the model’s answer, if the model service provider signs the system-prompt hash or policy version, the client can detect inconsistency between the request and the claimed identity.

4. Anti-Response Splicing

Some proxies may stitch together answers from multiple models. This can be detected through response digests, segment markers, and overall signature verification. If the upstream service returns only fragments, the gateway should prevent unsigned or incomplete results from being passed through directly.

5. Anti-Field Forgery

Model identifiers, version numbers, timestamps, and policy fields should not be freely declared by proxies. Ideally, these fields should be included in the upstream signature and confirmed by client-side verification.

Risk-Based Governance: Matching Anti-Fraud Strength to Business Scenarios

Model authentication does not require the same strong solution for every scenario. Different businesses have different requirements for authenticity, compliance, and cost. A tiered strategy is therefore more practical.

1. High-Risk Scenarios

Examples include financial risk control, medical assistance, government and enterprise services, critical code generation, and automated decision-making. These scenarios should adopt strong anti-fraud controls:

• Upstream model services must provide signatures.
• Clients or gateways must enforce signature verification.
• Complete audit evidence must be retained.
• Golden evaluation sets should be used for continuous regression testing.
• Suspicious channels should be automatically circuit-broken.

2. Medium-Risk Scenarios

Examples include internal enterprise knowledge bases, customer-support assistance, marketing content generation, and data-analysis assistants. These scenarios can use medium-strength controls:

• Sampling-based signature verification
• Key-field validation
• Periodic evaluation
• Exception alerting
• Retaining masked audit records

3. Low-Risk Scenarios

Examples include internal experiments, creative drafts, and non-critical question answering. These scenarios can use lightweight controls:

• Record metadata returned by the model
• Perform periodic sampling tests
• Review obvious anomalies manually
• Avoid forcing complex signature systems unless necessary

Tiered governance avoids a one-size-fits-all approach. Strong anti-fraud mechanisms introduce additional fields, key management, and verification overhead. For low-risk scenarios, excessive design may increase system complexity without proportional benefit.

Practical Limits: Strong Anti-Fraud Requires Upstream Cooperation

It must be acknowledged that model authentication cannot be fully solved by the client alone. If the upstream model service does not provide signatures, does not publish model versions, or does not allow audit fields to be returned, the client may struggle to obtain strong proof. In that case, it can only rely on behavioral testing and statistical analysis, but these methods may suffer from false positives and delayed detection.

In addition, LLM outputs are probabilistic. The same model may produce different answers under the same prompt, so “different answers” alone cannot prove that a model was replaced. Statistical indicators, task distributions, and multi-round validation are needed to reduce misjudgment.

There is also the risk of proxies optimizing specifically for evaluations. If an evaluation set is fully public, proxy layers may cache, rewrite, or simulate answers to specific questions. Therefore, golden evaluation sets should include a portion of non-public dynamic questions and should be rotated regularly.

In the future, the industry needs more general standards for model responses. Examples include a unified response envelope, signature-algorithm negotiation, public-key distribution, model-version registration, timestamp services, audit interfaces, and exception-reporting standards. Only when model service providers, proxy layers, business applications, and clients follow shared standards can model anti-fraud be implemented at scale.

Conclusion: Moving LLM Services from Callable to Verifiable

The core contradiction of LLM proxy services is not whether a model can be called, but whether the model actually returned is the one that was claimed. Traditional content-based judgment is no longer sufficient for complex proxy chains. Developers need to shift their focus from “what the answer looks like” to “whether the call chain is verifiable.”

From an engineering perspective, the practical path is to combine multiple methods:

• Prefer upstream signatures and response evidence packages.
• Use behavioral fingerprints and golden evaluation sets when signatures are unavailable.
• Build gateway, audit, monitoring, and alerting capabilities at the platform layer.
• Apply strong verification to high-risk businesses.
• Use tiered governance for lower-risk scenarios.

This approach can improve the trustworthiness of model services and help detect and handle model substitution, degradation, cache impersonation, or tampering in time.

Model anti-fraud is not a single-point feature. It is an engineering system built around identity, integrity, time, version, audit, and monitoring. For enterprises and developers integrating LLM services, establishing verifiable call mechanisms earlier reduces later governance costs and moves model services from “usable” to “trusted, controllable, and auditable.”