VERIK
Editorial · Agentic AI Governance
VERIK / V024 / 17 JUN 2026
Agent IdentityGovernance

The Proxy That Knew Too Much

A June 2026 paper names the LLM API router as an application-layer man-in-the-middle and demonstrates a hardware-attested architecture that closes the gap. The architecture is six milliseconds slow and eight hundred fifty-one lines large. The institutional record does not yet name router attestation as a procurement primitive. The shape of the procurement clause that would name it is now visible.

On June 15, 2026, Sipeng Xie, Qianhong Wu, Hengrun Lu, Ziliang Sun, Bo Qi, Bo Qin, and Qin Wang posted The Proxy Knows Too Much: Sealing LLM API Routers with Attested TEEs to arXiv. The paper names a governance surface that has not appeared in the public agentic AI debate at the resolution the paper now provides. The surface is the LLM API router: the intermediary between an agent and the large language model the agent consults. The paper's threat model is structural, its construction is concrete, and its evaluation is on real-provider workloads.

The structural claim is direct. A router terminates the client's transport-layer security session and opens a separate upstream session, so the router holds the full agent interaction in plaintext. The router is therefore an application-layer man-in-the-middle. It can rewrite agent tool calls. It can swap dependencies for typosquatted packages. It can trigger attacks only under audit-evading conditions. It can passively exfiltrate secrets. Existing client-side defenses, the paper notes, are evadable.

The construction is named AEGIS. It is a provider-transparent attested API router whose data path is a client-verified faithful passthrough. Plaintext handling is confined to a small hardware-enclave component. Authentication, scheduling, accounting, and management stay on the untrusted host. The client verifies the enclave before releasing plaintext. The host can neither read nor alter the interaction. Plaintext leaves only toward destinations fixed by the measured image. The trusted path is eight hundred fifty-one lines. The relay overhead is about six milliseconds per request. The trusted path 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 found eight of ten and ten of ten planted invariant violations.

What the paper makes legible at the governance layer

The router has been an invisible component of the agentic stack. Public discussion of agent security has concentrated on the agent itself, on the agent-to-tool surface, and on the agent-to-agent surface. The Yang and Zhu coalition paper, reviewed elsewhere in this archive, sits above the agent-to-agent layer. The OWASP Agentic AI work, including the Securing Agentic Applications Guide, enumerates threats at the application layer. The Anthropic Frontier Red Team mapping of agentic attacks to MITRE ATT&CK categorizes adversary behavior at the technique layer. The Cloud Security Alliance Agentic AI work addresses principles at the governance layer.

The router has not been named at any of those layers. It is the component that every commercial agent traverses on every call. It is the component most likely to be operated by a third party the agent owner does not control. It is the component with the most visibility into agent behavior, because every prompt, every tool call, every response, and every error passes through it in plaintext. The paper makes the router visible.

The paper does not name MCP or A2A directly. The connection between the paper's threat model and those protocols is the editorial reading. The router under analysis sits beneath both. An agent that uses MCP to mediate tool access still terminates its conversation with the model at an upstream provider, and the provider's edge is reachable only through a router. An agent that uses A2A to coordinate with another agent still terminates its model conversation at an upstream provider through a router. The protocols above are not in scope of the AEGIS threat model. The router beneath them is.

What the construction demands of the institutional record

The construction is small and the performance is modest. A trusted base of eight hundred fifty-one lines is, by the standards of confidential-computing literature, an artifact a competent auditor can examine in a day. A relay overhead of six milliseconds per request is, by the standards of LLM inference latency, structurally negligible. The economic argument against deploying attested routers is therefore not a performance argument and not a complexity argument. It is an argument about who specifies the attested-router primitive at the institutional level and who requires it at the procurement level.

The institutional record on confidential computing is mature in adjacent domains. The federal posture on cryptographic modules is published as FIPS 140-3 and iterated through a public-iteration venue with a designated comment period. The federal posture on the post-quantum credential is being published as working drafts with a public GitHub repository and a public mailing list, as noted in recent NIST PIV updates. The federal posture on the application-layer intermediary between an agent and a model is not yet published at the same resolution. The category does not yet appear in the NIST AI Risk Management Framework Generative AI Profile. It does not yet appear in the Cloud Security Alliance research note on the CISA patch directive. It does not yet appear in published federal procurement language.

What would close the gap

The Xie and colleagues paper does not need new research to be procurement-relevant. The shape of the procurement clause that would invoke its primitive is visible from the construction itself.

The clause would name three things. It would name the attestation surface: a measured image of the router's data path that the client can verify before any plaintext crosses the router. It would name the boundary: which router operations belong inside the hardware enclave and which can stay on the untrusted host. The AEGIS paper provides one concrete answer, with plaintext handling inside and authentication, scheduling, accounting, and management outside. It would name the verification artifact the client receives: the measurement value, the binding between the measurement and the destinations the router is permitted to send plaintext to, and the cryptographic chain that lets the client check both. None of those three components requires a research advance. Each has a recognizable shape in confidential-computing literature and in adjacent FIPS-class artifacts.

The clause has institutional precedents to draw on. The same federal authorities that publish working drafts for credential algorithms have the standing to publish a working draft for an attested-router primitive. The same procurement instruments that require FIPS-validated cryptographic modules have the standing to require attestation of the application-layer intermediary an agent uses to reach a model. The same audit posture that asks for evidence that a credential was unrevoked at the time of use can ask for evidence that a router was measured at the time of use. None of those moves requires that AEGIS itself be the standard. The move is to open the venue.

What remains on the table:

The policy instruments and the deployment tempo are not aligned. The router is plaintext. The construction that would close the gap is published. The procurement clause that would invoke it has not been written.