Technical Summary: IPI-proxy

Problem Statement

The proliferation of web-browsing AI agents in enterprise environments has introduced a critical security vulnerability: Indirect Prompt Injection (IPI). Unlike direct prompt injection, where an adversary interacts with the model directly, IPI occurs when an agent retrieves third-party content (e.g., web pages, documents) containing hidden instructions that the model executes as legitimate user commands.

Current red-teaming methodologies and benchmarks fail to adequately address IPI in realistic enterprise settings due to three primary gaps:

1. Whitelist Mismatch: Existing benchmarks (e.g., BIPIA, InjecAgent) rely on adversarial pages hosted on attacker-controlled domains. Agents restricted to strict enterprise whitelists (e.g., *.clientcorp.com) cannot access these pages without violating policy, rendering the tests invalid for production-like scenarios.
2. Static Content: Benchmarks typically serve frozen, pre-built adversarial pages. This fails to simulate the "live" nature of real-world attacks where adversaries inject content into trusted domains via comments, wikis, or third-party widgets.
3. Model-Only Scope: General red-teaming tools (e.g., PyRIT, garak) and detection systems (e.g., Rebuff) probe the LLM API directly. They do not test the retrieval surface—the path by which untrusted content reaches a tool-using agent—where IPI most frequently manifests.

Methodology

The authors propose IPI-proxy, an open-source toolkit designed to bridge the gap between static benchmarks and live deployment. The core innovation is an architectural inversion: rather than forcing the agent to visit attacker-controlled URLs, IPI-proxy intercepts and modifies HTTP responses from domains the agent is already permitted to visit.

System Architecture

IPI-proxy operates as a network-level Man-in-the-Middle (MITM) proxy built on mitmproxy. It consists of five key components:

1. Proxy Addon: Registers a response handler that inspects outgoing HTTP responses. It validates the destination URL against a target pattern, ensures the content is HTML, and checks the injection budget before proceeding.
2. Unified Payload Library: A deduplicated JSONL file containing 820 attack strings extracted from six existing benchmarks (BIPIA, InjecAgent, AgentDojo, Tensor Trust, WASP, and LLMail-Inject). These are normalized under a unified schema.
3. Embedding Templates: To evade human inspection while remaining visible to LLMs, payloads are wrapped using three techniques:
   • HTML Comments: Placed inside <!-- --> blocks.
   • Invisible CSS: Wrapped in <div> elements styled with display: none and off-screen positioning.
   • Semantic Prose: Integrated into plausible editorial text, optionally generated by an LLM (e.g., Claude) for higher evasion.
4. HTML Injector: Inserts the wrapped payload into one of six specific locations within the HTML document (e.g., head_meta, body_top, sidebar, script_comment). If a specific anchor is missing, the system falls back to a coarser anchor to ensure injection success.
5. Exfiltration Tracker: A lightweight FastAPI service that logs callbacks. If an agent follows an injected instruction to send data to this tracker, the test is marked as a successful exfiltration.

Workflow

1. The agent requests a URL from a whitelisted domain.
2. The proxy forwards the request to the upstream server.
3. Upon receiving the original HTML response, the proxy selects a payload based on YAML-configured filters (attack type, source benchmark, severity).
4. The payload is wrapped and injected into the HTML at a configured insertion point.
5. The modified HTML is returned to the agent.
6. If the agent executes the injected instruction and contacts the exfiltration tracker, the event is logged.

Key Contributions

• Whitelist-Respecting Red-Teaming: IPI-proxy is the first tool to enable IPI testing against agents restricted to specific whitelists by modifying live responses from those trusted domains rather than serving mock pages.
• Unified Payload Source: It aggregates and deduplicates 820 attack vectors from six disparate research benchmarks, allowing for cross-benchmark evaluation and rotation within a single test session.
• Parameter-Sweep Evaluation: By decoupling the payload, embedding technique, and HTML insertion point, the tool enables systematic evaluation of an agent's susceptibility across a multi-dimensional attack surface.
• Agent-Agnostic Design: Unlike browser-extension-based tools, IPI-proxy operates at the network layer, making it compatible with headless fetchers, custom HTTP clients, and Model Context Protocol (MCP) tools.

Results and Evaluation

The paper presents IPI-proxy as a testing substrate rather than a defense mechanism. It does not report specific success rates against a particular model (e.g., "Model X failed 80% of the time") but rather demonstrates the feasibility and reproducibility of the testing methodology.

• The tool successfully intercepts and rewrites HTTP responses from whitelisted domains without modifying the upstream server.
• It supports a "parameter-sweep" evaluation regime that covers combinations of payloads, embeddings, and insertion points not simultaneously supported by existing benchmarks.
• The exfiltration tracker provides a ground-truth signal for successful attacks without requiring instrumentation of the agent itself, preserving the integrity of the test environment.

Significance

The authors position IPI-proxy as a necessary evolution in AI security testing. By shifting from static, mock-page benchmarks to dynamic, live-response interception, the tool allows security teams to:

1. Measure the vulnerability of web-browsing agents under the same egress restrictions and content sources they face in production.
2. Harden agents by providing a reproducible environment to test defensive strategies (such as input transformation or architectural isolation) against realistic IPI vectors.
3. Bridge the gap between academic benchmarks and enterprise deployment, ensuring that red-teaming efforts reflect the actual threat surface where IPI occurs.

The paper concludes that while IPI-proxy does not solve the IPI problem itself, it provides the critical infrastructure required to accurately assess and mitigate the risk before agents are deployed in sensitive enterprise environments.