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

1. Problem Statement

The paper identifies a critical security vulnerability in the architecture of Large Language Model (LLM) API routers. As agents increasingly rely on intermediaries to access multiple model providers, these routers act as application-layer man-in-the-middle (MitM) points. By terminating the client's Transport Layer Security (TLS) session and initiating a separate upstream session, the router holds the full request and response interaction in plaintext.

This structural design grants the router operator complete visibility and control over the agent's data, enabling four distinct classes of malicious attacks:

• AC-1 (Tool-call rewrite): The router can alter tool calls (e.g., shell commands) before they reach the client. Since the rewrite is schema-valid, the client executes the malicious command, potentially leading to remote code execution.
• AC-1.a (Typosquatting): The router can swap dependencies in install commands for typosquatted packages, bypassing domain-based allowlists and establishing a supply-chain foothold.
• AC-1.b (Trigger-gated attacks): The router can execute rewrites only under specific conditions (e.g., specific keywords or request counts), evading detection by auditors running finite probe sets.
• AC-2 (Passive exfiltration): The router can scan traffic for credentials and secrets, exfiltrating them without altering the interaction.

Existing client-side defenses (policy gates, anomaly screening) are shown to be evadable. The paper argues that a sound fix requires moving the trust boundary to a party the client can verify without relying on the provider's cooperation or the router operator's honesty.

2. Methodology: AEGIS

The authors propose AEGIS, a provider-transparent, attested API router that confines plaintext handling to a small, hardware-enforced enclave while leaving management functions on an untrusted host.

Core Architecture

AEGIS splits the router into two distinct trust domains:

1. The Untrusted Host: Handles authentication, account selection, scheduling, billing, and management. It communicates with the enclave via a narrow control channel that never carries the request/response body or network addresses.
2. The Attested Enclave (TEE): Runs a minimal, faithful data path. It terminates the client's TLS session, relays the request and response bytes verbatim to a fixed provider, and reports only usage telemetry to the host.

Key Mechanisms

• Faithful Passthrough: The enclave code performs no semantic transformation. It forwards requests and responses byte-for-byte. This ensures that the attestation of the code guarantees the integrity of the data flow.
• Fail-Closed Attestation: Before the client releases any plaintext (prompts, tool calls, credentials), a local sidecar verifies the enclave's remote attestation. The client only sends data if the enclave's measurement matches a pinned, audited value and binds to the current session.
• Destination Authority: The set of legitimate upstream destinations is "baked" into the enclave's measured image. The host can only request a route by name (policy), not by IP/URL. The enclave resolves this name to a fixed destination, preventing the host from redirecting traffic to malicious endpoints.
• Anchored Measurement (ARPA): The system uses an Audit, Reproduce, Pin, Attest protocol. Operators publish a reproducible build manifest signed and logged in a transparency log. Clients audit the source, reproducibly rebuild it to verify the measurement, and pin the result. This allows clients to trust the code without a central auditor.

3. Key Contributions

The paper outlines four primary contributions:

1. Provider-Transparent Design: A router architecture that closes all four malicious-router attack classes (AC-1, AC-1.a, AC-1.b, AC-2) under a precise malicious-operator model, without requiring provider-side changes.
2. Minimal Trusted Base: A confidentiality-first design where only the faithful passthrough runs in the enclave (851 lines of trusted code). Authentication and billing remain on the untrusted host, minimizing the Trusted Computing Base (TCB).
3. Measurement-Equals-Audited-Code: A construction using reproducible builds and transparency logs (ARPA protocol) that allows end-users or their agents to anchor trust without a central authority.
4. Empirical Evaluation: Comprehensive testing demonstrating that AEGIS blocks all four attack classes while maintaining low overhead. This includes adaptive tests, formal verification via ProVerif, and real-provider workload testing.

4. Results and Evaluation

The authors implemented AEGIS on AWS Nitro Enclaves and evaluated it against a plaintext-access baseline.

• Security Effectiveness: All four attack classes (AC-1 through AC-2) succeeded against the plaintext baseline but were completely blocked by AEGIS. Adaptive tests confirmed that the host cannot rewrite tool calls, inject typosquats, trigger conditional rewrites, or exfiltrate secrets.
• Formal Verification: A symbolic model using ProVerif confirmed the protocol ordering, attested release, and destination authority, falsifying the system when individual checks were removed.
• Auditability: In a seeded audit pilot, two commodity coding agents (Codex and Claude Code) successfully identified planted invariant violations (8/10 and 10/10 respectively) in the minimal trusted code, validating the claim that the small codebase is reviewable.
• Performance Overhead:
  • Latency: The local relay adds approximately 6 milliseconds per request for small payloads.
  • Scalability: Overhead grows with payload size due to encryption and boundary crossing (reaching ~183ms for 4MB payloads) but remains well below the latency of the model call itself.
  • Concurrency: The system handles moderate parallelism (up to 16 concurrent requests) with median latency staying within 20% of single-request values.
  • Streaming: The system preserves the provider's token cadence, adding no measurable jitter between tokens.

5. Significance and Claims

The paper claims that AEGIS represents the first minimal trusted-code, reproducible enclave retrofit of a widely deployed open-source router template. Its significance lies in:

• Shifting the Trust Boundary: It moves the trust boundary from the router operator (who cannot be fully trusted) to a verifiable hardware enclave, removing the operator's ability to misbehave rather than just detecting it after the fact.
• Closing the "Deployment Gap": It solves the problem where clients cannot assume providers will add new APIs or infrastructure for them. AEGIS works with existing providers and standard HTTPS upstreams.
• Preserving Agent Semantics: By strictly enforcing a "faithful passthrough," it ensures that agent tool calls and streaming structures remain intact, which is critical for coding agents that rely on exact provider responses.

The authors remain modest about limitations, acknowledging that the system relies on the hardware root of trust, does not protect against side-channel attacks, and currently leaves residual leakage regarding traffic size and timing. They note that while the current prototype is a single-hop solution, future work could extend trust to multi-hop attested upstreams.