cs.CRMar 15, 2026

AEX: Non-Intrusive Multi-Hop Attestation and Provenance for LLM APIs

Authors: Yongjie Guan

Organizations: Zhejiang University of Technology

Read PDF
Ask AI
Cite

Copy citation

DOINot available for this paper

Abstract

Hosted large language models are increasingly accessed through remote APIs, but the API boundary still offers little direct evidence that a returned output actually corresponds to the client-visible request. Recent audits of shadow APIs show that unofficial or intermediary endpoints can diverge from claimed behavior, while existing approaches such as fingerprinting, model-equality testing, verifiable inference, and TEE attestation either remain inferential or answer different questions. We propose AEX, a non-intrusive attestation extension for existing JSON-based LLM APIs. AEX preserves request, response, tool-calling, streaming, and error semantics, and instead adds a signed top-level attestation object that binds a client-visible request projection to either a complete response object or a committed streaming output. To support realistic deployments, AEX provides explicit request-binding modes, signed request-transform receipts for trusted intermediaries, and source-output / output-transform receipts for trusted output rewriting. For streaming, it separates checkpoint proofs for verified prefixes of an unmodified source stream from complete-output lineage for outputs that have been rewritten, buffered, aggregated, or re-packaged, preventing transformed outputs from being mistaken for source-stream prefixes. AEX therefore makes a deliberately narrow claim: a trusted issuer attests to a specific request-output relation, or to a specific complete-output lineage, at the API boundary. We present the protocol design, threat model, verification state machine, security and privacy analysis, an OpenAI-compatible chat-completions profile, and a reference TypeScript prototype with local conformance tests and microbenchmarks.

Figures & tables

Figure 1: High-level structure of AEX . Request-side commitments flow from the client-visible request and optional signed request_transforms ; output-side lineage, when present, flows from a source output through origin_output and output_transforms to the final output_commit . The terminal attestation binds these commitments to the returned response or stream without changing business-payload semantics.
Figure 2: Source-stream prefix mode in AEX . Request anchors seed the source stream chain, each committed JSON event contributes to the complete source-stream commitment, checkpoints may certify verified prefixes, and the terminal attestation seals the complete stream commitment. Protocol markers such as [DONE] remain outside the chain.
Figure 3: Complete-output-lineage mode in AEX . The delivered stream still has a request-anchored complete-output commitment, but checkpoints are forbidden and no verified prefix is exposed before the terminal attestation. Instead, the terminal attestation carries origin_output and output_transforms , which link the final delivered stream to a source complete output through a signed lineage that closes on both commitment values and output_mode .
Figure 4: Illustrative trusted request-transform chain. Each receipt is signed by a named intermediary, maps one request commitment into the next, and ultimately explains how the original request_commit becomes the attested effective_request_commit . The binding mode and nonce remain fixed across the chain, the receipts are conveyed on trusted control-plane channels rather than as ordinary client payload, and the note at right highlights the analogous output-side closure pattern over origin_output , output_transforms , output_commit , and output_mode .
Figure 5: Illustrative tampering attempt and detection path. The issuer emits a signed response, an attacker mutates the payload in transit, and the verifier rejects the result as tampered because the locally recomputed payload commitment no longer matches the attested commitment, even if the detached signature object itself still parses or verifies.
MechanismMain objectOnline API transaction bindingStreaming chunk semanticsPrimary question answered
HTTP Message Signatures [ 13 ]HTTP componentsPartial, genericNo LLM-specific chunk modelWhich HTTP components were signed, despite safe transformation?
C2PA [ 19 ]Media assetsNoNoWhat is the provenance history of this media asset?
in-toto / DSSE [ 20 , 21 ]Supply-chain metadataNot transaction-orientedNoWhat signed steps and artifacts formed a software supply chain?
LLMmap / MET [ 2 , 3 ]Output behaviorInferential onlyIndirectWhich model or distribution does this endpoint appear to serve?
SVIP [ 4 ]Model internals + outputsYes, but intrusiveNot targeted at API chunk streamsDid the provider likely use the requested open-source model?
TEE attestation / RA-WEBs / AttestLLM [ 7 , 6 , 5 ]Execution environmentIndirect unless coupled with app semanticsNo LLM-API semantics by defaultWhat measured code/environment is running?
Table 1: Positioning AEX against neighboring mechanisms. The table summarizes the design space rather than claiming mutual exclusivity.
Figure 6: Reference prototype topology used in the accompanying artifact. The public client surface terminates at the gateway verifier; the internal proxies model trusted request rewriting while the provider emits source-stream and terminal evidence; and the gateway stores a per-run trace with request, effective-request, SSE, checkpoint, and verifier-state diagnostics.
LayerCountMain coverage
Unit tests29Core request binding, attestation issuance/verification, output-lineage receipts, stream verification, and JWKS behavior
Integration tests25End-to-end gateway/proxy/provider flows, request/output transform chains, lineage scenarios, and negative-path verification states
Browser end-to-end tests6Public /v1/* API wiring, stream progress, diagnostics, and proxy configuration workflows
Table 2: Automated validation in the reference prototype.
ScenarioRunsMedian client completion (ms)Median first stream chunk (ms)Median gateway verification (ms)
Non-stream success20/20 verified2.287—0.495
Stream success (checkpoint)20/20 verified243.3711.7360.843
Transform-chain success20/20 verified2.609—0.952
Non-stream lineage success20/20 verified2.225—0.710
Stream lineage success20/20 verified243.0281.6661.491
Table 3: Local microbenchmarks on the reference lab stack. The table reports only the median latency figures used in the discussion text.
Appendix figures & tables1 asset

Supplementary material from the paper’s appendix.

Appendix

AEX can proveAEX does not prove
A trusted issuer signed a particular request-output relation.The response is factually true.
A streamed output was received in the committed order and count, subject to the terminal proof mode that was actually used.The provider used a specific internal model weight snapshot.
A request was transformed through a chain of explicitly signed, trusted transforms.No hidden prompts, private retrieval, or server-side policy text existed.
A final complete output descended from a source issuer’s complete output through an explicitly signed chain of trusted output transforms.Every hidden intermediate output in that lineage is visible to the client.
A non-streaming or streaming response is inconsistent with the attested commitments if tampered with.An accepted output transform is semantically correct, reasonable, or minimal absent external policy.
Appendix
Table 4: Claim boundary of AEX .
More in this topic

Remote Attestation

Remote attestation uses cryptographic evidence to let a verifier check the hardware and software state of a remote system.

See all 10 papers

Explore similar work

CardsList
Aug 30, 2026

AgentProv: Auditing Agentic LLM API Providers via Tool-use Policy Probes

Commercial LLM APIs advertise a specific foundation model, but the served backbone may be silently substituted, quantized, or wrapped, for example to save deployment costs. All existing audits decide backbone identity from the text-output channel, which is structurally fragile for agentic APIs because modern serving stacks (OpenAI, Anthropic, Gemini, Cloudflare Workers AI, LangGraph) discard text and expose only structured actions when the model calls a tool, and provider-injected system prompts can distort text distributions enough that text-channel tests falsely accuse honest providers of substituting the claimed model. We observe that recent agentic post-training internalizes tool-use directly into the weights, opening a new audit channel that the serving stack still exposes and that is largely invariant to deployment context. We introduce Agentic Provenance (AgentProv), the first action-based identity audit for agentic LLM APIs: AgentProv fingerprints a deployed model through its categorical tool-call distribution and decides identity via an MMD permutation test. AgentProv catches every substituted model (100% on 630 evaluated checkpoint pairs), while holding the false-positive rate under system-prompt injection at 7% (vs. 67% for MET and 53% for RUT). On third-party API endpoints, AgentProv's disagreements with MET are consistent with an independent token-count side-channel that detects provider-injected system prompts.

Xun Wang, Bihe Zhao, Michael Backes +2

CISPA Helmholtz Center for Information Security

LLM AuditingLanguage Model Fingerprinting
AskPDF
Jun 15, 2026

The Proxy Knows Too Much: Sealing LLM API Routers with Attested TEEs

Agents increasingly access large language models (LLMs) through API routers. A router terminates the client's transport-layer security session and opens a separate upstream session, so it holds the full interaction in plaintext. This makes the router an application-layer man-in-the-middle: it can rewrite agent tool calls, swap dependencies for typosquatted packages, trigger attacks only under audit-evading conditions, and passively exfiltrate secrets. Existing client-side defenses are evadable. We propose AEGIS, a provider-transparent attested API router whose data path is a client-verified faithful passthrough. AEGISconfines plaintext handling to a small hardware-enclave component while leaving authentication, scheduling, accounting, and management on the untrusted host. The client verifies the enclave before releasing plaintext. The host can neither read nor alter the interaction, and plaintext leaves only toward destinations fixed by the measured image. We show that all four malicious-router attack classes succeed against a plaintext-access baseline and are blocked by AEGIS, including adaptive tests against the same boundary. The trusted path is 851851 lines, carries three provider-native APIs without conversion, and completes every request under real-provider workload and concurrency. In a seeded audit pilot, two commodity coding agents find eight and ten of ten planted invariant violations. The local relay overhead is about six milliseconds per request.

Sipeng Xie, Qianhong Wu, Hengrun Lu +4

1Beihang University · 2Renmin University of China · 3Independent

Remote AttestationLLM Agent SecurityTrusted Execution EnvironmentsLLM Security
AskPDF
Aug 17, 2026

Ventor-QTest: Threat-Model-Driven Verification of Vendor-Hosted LLM APIs

As large language models become increasingly widespread, third-party providers that deploy open-weight models have become an important part of the ecosystem. Auditing the quality of their inference APIs is therefore an open problem. We formalize hosted model routing as a stochastic process and propose \mbox{Ventor-QTest}, a composite black-box audit that requires no probability information from the target API. Its repeated-request component sends each frozen constrained context to the target multiple times, reconstructs a categorical output distribution from the returned text counts, and reports average fidelity loss (AFL) as a null-bias-corrected, within-window mean coarsened-KL statistic. Its long-sequence component uses independent runs to report extreme fidelity loss (EFL) through the empirical upper tail of a run-level reference-centered-surprisal statistic. Across three logprob-capable route conditions, AFL shows strong linear descriptive agreement with a logprob-derived coarsened-KL comparator. Across seven route snapshots, 20-run sequence probes reveal route-specific EFL variation. AFL and EFL have little detectable route-level association with GPQA-Diamond accuracy. In contrast, pronounced EFL coincides with a decline in Terminal-Bench pass rate as task exposure increases. This pattern may arise because correctness in long-horizon tasks is more sensitive to extreme fidelity loss. These results motivate reporting AFL and EFL jointly, particularly when auditing long-horizon agentic tasks. The open-source implementation is available at https://github.com/Tencent/AI-Infra-Guard/tree/main/services/api_checker/ventor_qtest.

Xiangfan Wu, Zonghao Ying, Huiyu Wu +4

Tencent Zhuque Lab

LLM AuditingBlack-Box Model AuditingLLM Reliability
AskPDF