Scope and evidence

The verified research describes an implementation called Mine: an OpenAI-compatible FastAPI proxy that forwards requests to an upstream provider and conditionally applies attack conditions identified as AC-1, AC-1.a, AC-1.b, and AC-2. The same source describes companion client-side modules for three evaluated defense categories: a tool policy gate, response-side anomaly screening, and an append-only transparency log.

This is a report about an evaluated research implementation, not evidence that every FastAPI proxy has these features or that Mine is a generally available product. The supplied context does not include source code, installation instructions, request examples, benchmark results, or a complete implementation guide. Accordingly, this article does not invent API endpoints, code, configuration values, or guarantees that are absent from the evidence.

The distinction matters for engineering teams: a description of a research prototype can inform a threat model, but it is not sufficient documentation for copying a production architecture. Before implementing controls, consult the original paper and any linked artifacts, verify their current availability and contents, and review the design against your own deployment environment.

Step 1: Understand the intermediary threat model

The paper considers an attacker that operates a malicious LLM API router or has compromised a legitimate router. The described compromise paths include supply-chain compromise, insider access, or server-side exploitation. The key architectural fact in the source is that the client explicitly configures the router as its API endpoint. The router terminates the client-side TLS connection and originates a separate TLS connection to the upstream provider.

That arrangement places the router in an application-layer intermediary position by design. TLS on each network connection does not, by itself, prevent the configured router from handling the application request and response. According to the source, the intermediary can read, retain, rewrite, or fabricate request and response bodies, headers, and request metadata.

The paper names sensitive material that may cross this boundary: tool definitions, prompts, tool outputs, API keys, and returned tool-call payloads across OpenAI-, Anthropic-, and Gemini-style interfaces. These are not interchangeable categories. A prompt may contain instructions or business data; a tool definition describes capabilities exposed to the model; a tool result can contain information returned by an application; and a tool-call payload may request an action in a connected system. The source’s threat model says the router may be able to handle these materials. It does not establish that every deployment sends every category, or that every router stores or modifies them.

For a security review, start by documenting the configured endpoint and the party operating it. Identify which systems can change that endpoint, deploy or update the router, access its runtime, or inspect its traffic at the application layer. The research context supports asking these questions; it does not prescribe a vendor-selection checklist or a specific network topology.

Step 2: Map the data that passes through the router

Build an inventory from the actual client configuration and request flows. Record whether requests include prompts, tool descriptions, tool results, credentials, or other metadata, and whether responses include natural-language content or tool-call data. Keep the inventory factual: do not assume a field is absent merely because it is not visible in a user interface.

The paper notes that a router may keep cross-request state. That possibility changes the review: security analysis should not be limited to a single request in isolation. Consider whether an intermediary can relate activity across requests and what impact that could have in the particular application. The supplied source does not specify a retention period, storage mechanism, or exact cross-request attack sequence, so do not treat any particular retention behavior as a confirmed fact.

Pay special attention to credentials and tool payloads. The source explicitly includes API keys and returned tool-call payloads in the material an intermediary may handle. This is a reason to include those elements in the threat assessment, not proof that a particular key was exposed or that a particular tool action was executed. Determine what your client...