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

Yongjie Guan

cs.CRMar 15, 2026

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

Authors: Yongjie Guan

Organizations: Zhejiang University of Technology

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.

Mechanism	Main object	Online API transaction binding	Streaming chunk semantics	Primary question answered
HTTP Message Signatures [ 13 ]	HTTP components	Partial, generic	No LLM-specific chunk model	Which HTTP components were signed, despite safe transformation?
C2PA [ 19 ]	Media assets	No	No	What is the provenance history of this media asset?
in-toto / DSSE [ 20 , 21 ]	Supply-chain metadata	Not transaction-oriented	No	What signed steps and artifacts formed a software supply chain?
LLMmap / MET [ 2 , 3 ]	Output behavior	Inferential only	Indirect	Which model or distribution does this endpoint appear to serve?
SVIP [ 4 ]	Model internals + outputs	Yes, but intrusive	Not targeted at API chunk streams	Did the provider likely use the requested open-source model?
TEE attestation / RA-WEBs / AttestLLM [ 7 , 6 , 5 ]	Execution environment	Indirect unless coupled with app semantics	No LLM-API semantics by default	What 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.

Layer	Count	Main coverage
Unit tests	29	Core request binding, attestation issuance/verification, output-lineage receipts, stream verification, and JWKS behavior
Integration tests	25	End-to-end gateway/proxy/provider flows, request/output transform chains, lineage scenarios, and negative-path verification states
Browser end-to-end tests	6	Public /v1/* API wiring, stream progress, diagnostics, and proxy configuration workflows

Table 2: Automated validation in the reference prototype.

Scenario	Runs	Median client completion (ms)	Median first stream chunk (ms)	Median gateway verification (ms)
Non-stream success	20/20 verified	2.287	—	0.495
Stream success (checkpoint)	20/20 verified	243.371	1.736	0.843
Transform-chain success	20/20 verified	2.609	—	0.952
Non-stream lineage success	20/20 verified	2.225	—	0.710
Stream lineage success	20/20 verified	243.028	1.666	1.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 prove	AEX 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 .

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

AgentProv: Auditing Agentic LLM API Providers via Tool-use Policy Probes
Aug 30, 2026Xun Wang, Bihe Zhao, Michael Backes +2LLM Auditing Language Model Fingerprinting
CISPA Helmholtz Center for Information Security
The Proxy Knows Too Much: Sealing LLM API Routers with Attested TEEs
Jun 15, 2026Sipeng Xie, Qianhong Wu, Hengrun Lu +4Remote Attestation LLM Agent Security
1Beihang University · 2Renmin University of China · 3Independent
Ventor-QTest: Threat-Model-Driven Verification of Vendor-Hosted LLM APIs
Aug 17, 2026Xiangfan Wu, Zonghao Ying, Huiyu Wu +4LLM Auditing Black-Box Model Auditing
Tencent Zhuque Lab

Aug 30, 2026J/K move · Enter open · S save

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

Xun Wang, Bihe Zhao, Michael Backes, Franziska Boenisch+1

CISPA Helmholtz Center for Information Security

LLM Auditing Language Model Fingerprinting

Open paper AskPDF arXiv

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.

Abstract

Remote Attestation

Explore similar work

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

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

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