Prompt injection stoppas inte av ett filter – lås agentens verktyg

Skydda en verktygsanvändande AI-agent mot prompt injection genom att begränsa dess åtkomst utanför modellen. Skilj hämtat innehåll från styrande instruktioner och låt en separat policy avgöra vilka data agenten får läsa och vilka åtgärder dess verktyg får utföra. En instruktion gömd i en webbsida eller ett mejl ska inte ensam kunna ge agenten nya befogenheter.

Ett textfilter kan fånga vissa angrepp, men kan inte avgöra om en användare har rätt att skicka kunduppgifter eller radera ett ärende. OWASP:s vägledning om prompt injection beskriver indirekta angrepp via externt innehåll och rekommenderar att filtrering kombineras med åtskilda instruktioner och data, begränsade verktygsbehörigheter och mänskliga godkännanden. Inför skydden i den ordningen som agentens uppdrag kräver: definiera åtkomsten, begränsa verktygen, säkra besluten och pröva att spärrarna håller.

Avgränsa uppdraget och håll externa data på sin plats

Skriv först ned vad agenten ska åstadkomma, vilka källor som behövs och vilka åtgärder som ligger utanför uppdraget. Det ger en konkret gräns för både verktygspolicyn och testerna. Om agenten ska sammanfatta ärenden behöver den kanske läsa en bestämd ärendekö, men den behöver inte därför kunna ändra ärenden, öppna andra användares köer eller skicka innehållet vidare.

Behandla webbsidor, mejl, dokument, sökresultat och verktygssvar som data även när de innehåller formuleringar som ser ut som kommandon. En hämtad sida kan i ett tänkt test be agenten att skicka alla kundposter till en extern adress. Agenten får använda sidan för att besvara användarens fråga, men sidans text ska inte ändra uppdraget eller skapa ett tillåtet anrop till ett sändverktyg. Märk upp innehållets ursprung och håll det skilt från systemets policy och användarens godkända begäran.

Samma gräns gäller minnet. Låt inte ett läst dokument bli en bestående regel för senare uppgifter. Bestäm vilka uppgifter som får sparas, vilken användare eller session de hör till och när de ska tas bort. Granska också vad som hamnar i agentens arbetskontext: känsliga uppgifter som aldrig behövs för uppdraget bör inte följa med till modellen eller nästa verktygsanrop.

Ge agenten en egen identitet och smala verktyg

NCSC:s interimistiska råd rekommenderar att agenter får egna identiteter, minsta nödvändiga behörighet och kortlivade autentiseringsuppgifter samt att deras körmiljö och åtkomst avgränsas efter risk. Råden är avsedda att hjälpa organisationer fatta beslut medan myndigheten arbetar med formell vägledning. Börja därför med att inventera varje verktyg och den resurs som verktyget faktiskt kan nå, inte bara dess namn i agentens verktygslista.

Dela upp läsning och skrivning och begränsa båda till namngivna resurser. En funktion som kan läsa en avgränsad ärendekö är lättare att kontrollera än ett allmänt databasverktyg. Ta bort fri kommandokörning och obegränsad nätåtkomst om uppdraget inte kräver dem. För skrivande funktioner behöver policyn dessutom ange tillåtna åtgärder, mål och parametrar. Börja gärna med enbart läsbehörighet och öppna skrivning först när dess godkännande och loggning fungerar.

Agentens identitet ska vara skild från medarbetarens konto och från andra agenters identiteter. Om ett verktyg kräver en hemlighet kan en mellanliggande tjänst lägga till autentiseringsuppgiften efter att anropet har godkänts, så att modellen inte får läsa den. Kör verktygen i en lämpligt isolerad miljö och begränsa vilka nätverksmål de kan nå. En spärr i verktygslagret måste gälla även när modellen formulerar ett övertygande skäl för ett annat anrop.

Kontrollera behörigheten vid körningstillfället mot användare, agentidentitet, verktyg, målresurs och normaliserade parametrar. Samma kontroll ska gälla anrop som följer på hämtat innehåll och anrop som modellen själv föreslår under arbetet. Om en agent med läsrätt begär skrivning ska verktyget neka åtgärden; ett avvisande svar i chatten är inget bevis för att den tekniska spärren fungerade.

Bind mänskliga godkännanden till den faktiska åtgärden

Klassificera åtgärder i verktygspolicyn innan agenten används. En sökning i ett avgränsat arkiv kan tillåtas automatiskt, medan utskick av uppgifter, behörighetsändringar och radering kan kräva mänskligt godkännande. Låt inte agentens egen beskrivning av risk avgöra vilken kontroll som används: även den beskrivningen kan påverkas av text som agenten har läst.

Den som godkänner ska se vad som kommer att utföras: verktyg, mottagare eller målresurs, relevanta parametrar och den användare som begärde åtgärden. Knyt godkännandet till just dessa värden, gör det kortlivat och hindra återanvändning. Om agenten ändrar mottagare eller innehåll efter granskningen måste ett nytt godkännande krävas. Ett allmänt ja till agentens plan får inte fungera som tillstånd för senare ändrade anrop.

Den slutliga kontrollen hör hemma i komponenten som utför åtgärden. Den ska själv pröva behörighet, policy och godkännandets giltighet innan den använder sina autentiseringsuppgifter. Neka anropet om godkännandet saknas, har löpt ut eller inte matchar parametrarna. Neka också när policyn inte går att läsa eller ett nödvändigt granskningsbeslut inte kan loggas.

Logga besluten och gör avstängningen verklig

En granskningslogg ska visa kedjan från uppdrag till verktygsanrop och resultat. Registrera agentens identitet, verktyg och mål, tillämpad policyversion, beslut om tillåtelse, eventuellt godkännande och utfallet. Skydda loggarna mot ändring och begränsa känsligt innehåll i dem. En logg som kopierar nycklar eller fullständiga personuppgifter skapar själv en ny åtkomstväg.

Larma vid upprepade nekade anrop, försök mot nya nätverksmål och ovanligt många verktygsanrop. Sätt gränser för hur länge agenten får fortsätta, hur många gånger den får försöka igen och hur långa anropskedjor den får skapa. Sådana gränser ger en ansvarig person tid att ingripa och hindrar att ett fel eller ett injicerat uppdrag driver agenten vidare utan kontroll.

En stoppfunktion behöver bryta både agentens fortsatta körning och dess åtkomst till verktyg och nätverk. Pröva den med en ofarlig pågående uppgift: utlös stoppet och kontrollera att nya anrop nekas och att redan startade jobb hanteras enligt den avsedda avbrottsregeln. Att avsluta modellens svar räcker inte om ett verktygsjobb fortsätter efteråt.

Låt attacktester sätta gränsen för release

OWASP:s checklista för AI-agenter rekommenderar strukturerade säkerhetstester före produktion och efter väsentliga ändringar i promptar, verktyg, minne, hämtning av information, policy eller modellleverantör. Den rekommenderar också regressionstester för tidigare angrepp och att releaser blockeras när riskfyllda verktygspolicyer, godkännandelogik eller behörigheter ändras utan uppdaterade tester.

Bygg testfall kring de gränser agenten faktiskt har. Låt en injicerad webbsida begära ett otillåtet verktyg, ett dokument försöka lägga en bestående instruktion i minnet och ett verktygssvar begära utskick av känsliga data. Prova också att byta mottagare efter godkännande och att nå en annan användares resurs. Använd ofarliga testdata och kontrollera det verkliga verktygsutfallet och loggen, inte bara agentens formulering i chatten.

Som releasevillkor bör ett otillåtet verktygsanrop nekas, ett ändrat anrop kräva nytt godkännande och stoppfunktionen hindra fortsatt åtkomst. Blockera releasen om något av dessa fall misslyckas eller om utvidgade behörigheter saknar motsvarande test. Spara vilken agentversion, verktygspolicy och konfiguration för hämtad information som prövades. Då går det att avgöra om en senare ändring fortfarande omfattas av de kontroller som faktiskt testades.