Technische Samenvatting: IPI-proxy

Probleemstelling

De proliferatie van AI-agenten voor webbrowsing in enterprise-omgevingen heeft een kritieke beveiligingskwetsbaarheid geïntroduceerd: Indirecte Prompt Injectie (IPI). In tegenstelling tot directe prompt injectie, waarbij een adversary direct met het model interacteert, treedt IPI op wanneer een agent inhoud van derden (bijvoorbeeld webpagina's, documenten) ophaalt die verborgen instructies bevatten die het model uitvoert als legitieme gebruikerscommando's.

Huidige red-teaming-methodologieën en benchmarks slagen er niet in om IPI in realistische enterprise-omgevingen adequaat aan te pakken vanwege drie primaire gaten:

1. Whitelist-mismatch: Bestaande benchmarks (bijvoorbeeld BIPIA, InjecAgent) vertrouwen op adversary-pagina's die gehost worden op door de aanvaller gecontroleerde domeinen. Agenten die beperkt zijn tot strikte enterprise-whitelists (bijvoorbeeld *.clientcorp.com) kunnen deze pagina's niet bereiken zonder het beleid te schenden, waardoor de tests ongeldig zijn voor scenario's die lijken op productieomgevingen.
2. Statische inhoud: Benchmarks serveren doorgaans bevroren, vooraf gebouwde adversary-pagina's. Dit simuleert niet de "live" aard van echte aanvallen waarbij adversary's inhoud injecteren in vertrouwde domeinen via commentaren, wiki's of widgets van derden.
3. Enkel model-bereik: Algemene red-teaming-tools (bijvoorbeeld PyRIT, garak) en detectiesystemen (bijvoorbeeld Rebuff) onderzoeken de LLM-API direct. Ze testen niet het ophaaloppervlak – het pad waarmee inhoud van onbetrouwbare bronnen een agent die hulpmiddelen gebruikt bereikt – waar IPI het meest frequent voorkomt.

Methodologie

De auteurs stellen IPI-proxy voor, een open-source toolkit ontworpen om de kloof tussen statische benchmarks en live implementatie te overbruggen. De kerninnovatie is een architecturale inversie: in plaats van de agent te dwingen URLs van door de aanvaller gecontroleerde domeinen te bezoeken, onderschept en wijzigt IPI-proxy HTTP-antwoorden van domeinen die de agent reeds toegestaan is te bezoeken.

Systeemarchitectuur

IPI-proxy werkt als een proxy op netwerkniveau Man-in-the-Middle (MITM) gebouwd op mitmproxy. Het bestaat uit vijf kerncomponenten:

1. Proxy Addon: Registreert een response-handler die uitgaande HTTP-antwoorden inspecteert. Het valideert de bestemmings-URL tegen een doelpatroon, zorgt ervoor dat de inhoud HTML is, en controleert het injectiebudget alvorens verder te gaan.
2. Unificatie Payload-bibliotheek: Een gedupliceerd JSONL-bestand met 820 aanvalstekenreeksen die zijn ontleend aan zes bestaande benchmarks (BIPIA, InjecAgent, AgentDojo, Tensor Trust, WASP en LLMail-Inject). Deze zijn genormaliseerd onder een uniek schema.
3. Embedding-sjablonen: Om menselijke inspectie te ontlopen terwijl ze zichtbaar blijven voor LLM's, worden payloads ingepakt met drie technieken:
   • HTML-commentaren: Geplaatst binnen <!-- --> blokken.
   • Onzichtbare CSS: Omhuld in <div>-elementen gestyled met display: none en positionering buiten het scherm.
   • Semantische proza: Geïntegreerd in plausibele redactionele tekst, optioneel gegenereerd door een LLM (bijvoorbeeld Claude) voor hogere ontvluchting.
4. HTML Injector: Voegt de ingepakte payload in op een van zes specifieke locaties binnen het HTML-document (bijvoorbeeld head_meta, body_top, sidebar, script_comment). Als een specifieke ankerpunt ontbreekt, valt het systeem terug op een grover ankerpunt om injectiesucces te garanderen.
5. Exfiltratie-tracker: Een lichtgewicht FastAPI-service die callbacks logt. Als een agent een ingejecteerde instructie volgt om data naar deze tracker te sturen, wordt de test gemarkeerd als een geslaagde exfiltratie.

Werkflow

1. De agent vraagt een URL op van een gewhitelisted domein.
2. De proxy stuurt het verzoek door naar de upstream-server.
3. Bij ontvangst van het originele HTML-antwoord selecteert de proxy een payload op basis van YAML-geconfigureerde filters (aanvalstype, bronbenchmark, ernst).
4. De payload wordt ingepakt en ingejecteerd in de HTML op een geconfigureerd invoegpunt.
5. Het gewijzigde HTML wordt teruggegeven aan de agent.
6. Als de agent de ingejecteerde instructie uitvoert en contact opneemt met de exfiltratie-tracker, wordt het gebeurtenis gelogd.

Belangrijkste Bijdragen

• Whitelist-respecterende Red-Teaming: IPI-proxy is het eerste instrument dat IPI-testen mogelijk maakt tegen agenten die beperkt zijn tot specifieke whitelists door live antwoorden van die vertrouwde domeinen te wijzigen in plaats van mock-pagina's te serveren.
• Unificatie Payload-bron: Het aggregeert en deduplicatieert 820 aanvalsvectoren uit zes uiteenlopende onderzoeksbenchmarks, wat cross-benchmark evaluatie en rotatie binnen één testsessie mogelijk maakt.
• Parameter-sweep evaluatie: Door de payload, de embedding-techniek en het HTML-invoegpunt te ontkoppelen, stelt het instrument een systematische evaluatie van de vatbaarheid van een agent over een multidimensionaal aanvalsvlak in staat.
• Agent-onafhankelijk ontwerp: In tegenstelling tot tools op basis van browserextensies, werkt IPI-proxy op de netwerklagen, waardoor het compatibel is met headless fetchers, aangepaste HTTP-clients en Model Context Protocol (MCP)-tools.

Resultaten en Evaluatie

Het artikel presenteert IPI-proxy als een testsubstraat in plaats van een verdedigingsmechanisme. Het rapporteert geen specifieke succespercentages tegen een bepaald model (bijvoorbeeld "Model X faalde 80% van de tijd"), maar demonstreert eerder de haalbaarheid en reproduceerbaarheid van de testmethodologie.

• Het instrument onderschept en herschrijft succesvol HTTP-antwoorden van gewhitelisted domeinen zonder de upstream-server te wijzigen.
• Het ondersteunt een "parameter-sweep" evaluatieregime dat combinaties van payloads, embeddings en invoegpunten bestrijkt die niet gelijktijdig worden ondersteund door bestaande benchmarks.
• De exfiltratie-tracker biedt een ground-truth-signaal voor geslaagde aanvallen zonder instrumentatie van de agent zelf, waardoor de integriteit van de testomgeving behouden blijft.

Betekenis

De auteurs positioneren IPI-proxy als een noodzakelijke evolutie in AI-beveiligingstesten. Door over te stappen van statische, mock-pagina-benchmarks naar dynamische, live-response-onderschepping, stelt het instrument beveiligingsteams in staat om:

1. De kwetsbaarheid van webbrowsing-agenten te meten onder dezelfde egress-beperkingen en inhoudsbronnen die ze in productie tegenkomen.
2. Agenten te versterken door een reproduceerbare omgeving te bieden om defensieve strategieën (zoals inputtransformatie of architecturale isolatie) te testen tegen realistische IPI-vectoren.
3. De kloof te overbruggen tussen academische benchmarks en enterprise-implementatie, zodat red-teaming-inspanningen de werkelijke bedreigingsomgeving weerspiegelen waar IPI voorkomt.

Het artikel concludeert dat hoewel IPI-proxy het IPI-probleem zelf niet oplost, het de kritieke infrastructuur biedt die nodig is om het risico nauwkeurig te beoordelen en te mitigeren voordat agenten worden ingezet in gevoelige enterprise-omgevingen.