Adversariell testning av LLM-applikationer, agenter och MCP-integrationer: prompt injection, dataläckage, missbruk av verktyg och utbrytning från den avsedda uppgiften.
En applikation som bygger på en språkmodell tar emot instruktioner från allt den läser: användaren, ett hämtat dokument, innehållet på en webbsida, utdata från ett verktyg. Den kan inte på ett tillförlitligt sätt skilja en instruktion från data. När modellen kan anropa verktyg, skicka meddelanden eller skriva till en databas blir en mening som är gömd i ett dokument en handling i dina system.
Vi testar hela applikationen och inte bara modellen: prompterna, pipelinen för hämtning, verktygen och deras behörigheter, agenterna och de protokoll som kopplar samman dem. Frågan är vad en angripare kan få systemet att göra, läsa eller avslöja, och om skydden runt modellen håller när modellen själv inte gör det.
01Omfattning
Vad vi testar
Direkt och indirekt prompt injection via all indata som modellen läser
Röjande av systemprompter, hemligheter och andra användares eller tenanters data
Retrieval-augmented generation: förgiftning, åtkomstkontroll i dokumentlagret
Verktyg och funktionsanrop: överdrivna behörigheter, osäkra parametrar, confused deputy
Agenter: kapning av mål, förgiftning av minnet, osäker autonomi, förtroende mellan agenter
Servrar för Model Context Protocol: autentisering, förgiftning av verktyg, kommandokörning
Hantering av utdata: injektion i webbläsare, skal, frågor och efterföljande system
Skyddsräcken och filter: kringgående genom kodning, språk, rollspel och attacker över flera meddelanden
Resursförbrukning och missbruk som driver upp kostnader
02Arbetssätt
Så utförs arbetet
01
Granskning av arkitekturen
Vi kartlägger vad modellen läser, vad den kan anropa och med vems behörigheter. De flesta kritiska fynd syns redan i det här skedet, som en förtroendegräns som saknas.
02
Adversariell testning
Indata skapas för hand och genereras i stor skala mot varje kanal in i modellen. En lyckad attack reduceras till den minsta indata som återskapar den.
03
Missbruk av verktyg och agenter
Vi använder injicerade instruktioner för att styra verktyg och agenter: för att läsa det som inte ska gå att läsa, för att agera i en annan användares namn, för att ta oss från ett system till nästa.
04
Validering av skydden
Filter, skyddsräcken och godkännandesteg testas vart för sig. Rapporten anger vilket skydd som stoppade vilken attack och vilket som inte stoppade någon.
Poäng och vektor för allvarlighetsgraden hos varje fynd.
FIRST
06Frågor
Frågor om den här tjänsten
Testar ni modellen eller applikationen?
Applikationen. Basmodellens säkerhet är dess leverantörs ansvar. Det du har kontroll över, och det som angripare utnyttjar, är hur modellen är kopplad till dina data och dina verktyg.
Prompt injection kan inte åtgärdas helt. Vad är poängen med att hitta den?
Poängen är att veta vad som följer av den. Om injektionen leder till ett felaktigt svar är det en kvalitetsfråga. Om den leder till ett e-postmeddelande som skickas i användarens namn är det en sårbarhet i behörigheterna runt modellen, och den kan åtgärdas.
Använder ni våra data för att träna eller prompta externa AI-tjänster?
Nej. Kunddata, prompter och fynd skickas inte till offentliga AI-tjänster och används inte för träning. Verktyg som bygger på språkmodeller körs i miljöer som vi har kontroll över.
Täcker det här kraven i EU:s AI-förordning?
Adversariell testning är en av de åtgärder som förordningen hänvisar till för vissa system och modeller. Rapporten dokumenterar metod, omfattning och resultat i en form som lämpar sig som bevis. Om och hur förordningen gäller ditt system är en juridisk fråga som vi inte besvarar.