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

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 (6)

• 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.