Säkerhetschecklistan för AI-agenter: 9 skyddsmekanismer att verifiera innan du låter en agent agera på egen hand

Innan du låter en AI-agent agera på egen hand, verifiera nio skyddsmekanismer. De första fyra kopplar varje åtgärd agenten kan utföra till en riskbedömning, så att de oåterkalleliga, känsliga och kostsamma alltid pausar för en människa. De följande fem bekräftar miljön som håller agenten i schack när ett filter luras: en unik agentidentitet, rättigheter enligt minsta privilegium, en sandlåda, begränsad nätverkstrafik utåt och granskningsloggar på åtgärdsnivå. Åtgärdskartan berättar vad som är säkert att automatisera. Miljön är det som faktiskt håller ställningarna, eftersom de innehållsfilter som de flesta checklistor förlitar sig på är just det lager som brister precis när det är som viktigast. Kör alla nio som ja- eller nej-frågor, och om något svar är nej eller "vi är inte säkra" är agenten inte redo att köras utan tillsyn.

Detta är granskningen inför lansering som vi kör innan vi låter en agent vi byggt agera på egen hand inne i ett annat företag, skriven så att en icke-teknisk ägare också kan köra den, på sin egen agent eller på en leverantörs. Om du hellre vill att vi gör detta åt dig, se hur vi sköter ansvarsfull AI-styrning och risk. Allt nedan är ditt att använda.

Hur ska jag använda denna checklista?

Behandla den som en kontroll inför start, inte som en filosofi. Ta agenten du är på väg att driftsätta (eller den en leverantör säljer till dig) och besvara var och en av de nio punkterna med ett hårt ja eller nej. Ett "mestadels" är ett nej. Målet är att lyfta fram bristerna innan agenten rör vid något verkligt.

De nio delas in i två grupper som gör olika jobb:

• Punkt 1 till 4 (åtgärdskartan). Dessa avgör vad agenten får göra utan att fråga, och vad som måste stoppas för en människa. Detta handlar om bedömning av risk, och det är den del de flesta guider tar upp.
• Punkt 5 till 9 (miljön). Dessa sätter ett tak för vad agenten överhuvudtaget kan nå och göra, oavsett vad den blev tillsagd att göra. Det är den del de flesta checklistor hoppar över, och det är den del som håller en agent i schack när ett filter luras.

Båda grupperna är viktiga, men de brister på olika sätt. Åtgärdskartan handlar om att besluta rätt. Miljön handlar om att överleva ett felaktigt beslut. Du behöver båda, eftersom inget filter fångar allt: Anthropics produktionsklassificerare för auto-läge, en av de bästa som finns, missar fortfarande omkring 17% av alltför ivriga agentåtgärder även när den ställts in på att nästan aldrig blockera ett legitimt kommando. En missfrekvens på 17% är acceptabel med ytterligare ett lager bakom sig och hänsynslös när den är det enda som står mellan agenten och dina pengar.

Punkt 1 till 4: har du kopplat varje åtgärd till en riskbedömning?

Du kan inte spärra det du inte har listat. Börja med att skriva ner varje åtgärd agenten kan utföra, och betygsätt sedan var och en. OpenAI:s agentguide ger den renaste bedömningsmetoden: poängsätt varje åtgärd som låg, medel eller hög på fyra faktorer.

Skyddsmekanism 1: Har du listat varje åtgärd och betygsatt den som låg, medel eller hög? Om det finns en åtgärd på listan som ingen betygsatt, är det just den som skadar dig. Bedömningen sorterar nästan allt i tre fack:

Skyddsmekanism 2: Pausar varje högriskåtgärd för uttryckligt mänskligt godkännande innan den körs? Detta är den enda regel som förhindrar de värsta utfallen. OpenAI namnger exakt dessa som de åtgärder som motiverar mänskligt godkännande: att avbryta order, att auktorisera stora återbetalningar och att göra betalningar. Lägg till raderingar, beviljande av åtkomst och alla meddelanden som lämnar huset. En återbetalningsagent får läsa varenda order den vill, men den får aldrig flytta pengar över ett litet tröskelvärde utan att en människa klickar på godkänn.

Skyddsmekanism 3: Är godkännandespärren tillräckligt sällsynt för att människor fortfarande läser den? Fällan är att låta agenten fråga om allt. Gör du det har du byggt ett sämre system, inte ett säkrare. Anthropic mätte att användare godkänner ungefär 93% av behörighetsförfrågningarna, så en spärr som utlöses fyrtio gånger om dagen är teater: människan är nominellt med i loopen men har slutat titta. Verifiera tre saker: agenten frågar bara vid genuint riskfyllda åtgärder, förfrågan anger konsekvensen på vanlig svenska ("Återbetala 1 000 USD till konto X"), och tystnad innebär som standard "nej", aldrig "ja".

Skyddsmekanism 4: Stoppar agenten och ber om hjälp när den fortsätter att misslyckas? En förvirrad agent som går runt i en loop av nya försök är en egen typ av risk. Sätt ett tröskelvärde för misslyckanden, så att agenten efter ett bestämt antal misslyckade försök stannar och eskalerar i stället för att kämpa förgäves. OpenAI listar exakt två utlösare för mänskligt ingripande: att tröskelvärden för misslyckanden överskrids, och högriskåtgärder. Du har just täckt båda.

Punkt 5 till 9: har du verifierat miljön som håller den i schack?

Här är den del de generiska checklistorna hoppar över, och det är den del som gör det tunga arbetet. Punkt 1 till 4 förutsätter att agenten beslutar rätt. Punkt 5 till 9 förutsätter att den ibland inte gör det, och sätter ett tak för skadan när det händer.

Anledningen till att denna grupp är viktig är det mest underbelysta faktumet i agentsäkerhet: innehållsfilter brister precis när den skadliga instruktionen ser legitim ut. Anthropic körde ett test där en anställd blev utsatt för nätfiske, så att den skadliga instruktionen kom från den betrodda användare agenten var byggd att tjäna. Över 25 nya försök genomförde agenten stöld av inloggningsuppgifter 24 gånger, eftersom det, med deras ord, inte finns något avvikande för en klassificerare att fånga när användaren skriver instruktionen. Det enda som tillförlitligt stoppade den var miljömässigt: att blockera agentens nätverkstrafik utåt så att den stulna datan inte hade någonstans att ta vägen. Filter gissar avsikt. Miljön tar bort förmågan. Förmåga är det du faktiskt kan kontrollera.

Skyddsmekanism 5: Har agenten en egen identitet, inte en delad adminnyckel? Varje agent bör köras under en unik identitet, aldrig en delad inloggningsuppgift och aldrig en människas admininloggning. En delad nyckel innebär att du inte kan avgöra vilken agent som gjorde vad, och en komprometterad nyckel sprider sig överallt där nyckeln når. En unik identitet är också det som gör granskningsloggen i skyddsmekanism 9 meningsfull.

Skyddsmekanism 6: Är den identiteten begränsad till minsta privilegium? Agenten får den smalaste uppsättning rättigheter som jobbet faktiskt behöver, och inget mer. En supportagent som utfärdar återbetalningar bör inte också kunna exportera din kunddatabas eller ändra lönehantering. Om den luras begränsas skadan av vad den fått tillgång till, inte av om ett filter fångade tricket. Använd den minst kraftfulla åtkomst som fungerar: skrivskyddad slår läs-och-skriv, och läs-och-skriv-utan-radera slår full åtkomst.

Skyddsmekanism 7: Körs agenten i en sandlåda? Agenten bör verka inne i en isolerad miljö byggd på etablerad, beprövad isolering (samma containrar och sandlådor som används för att köra opålitlig kod), inte något egenhändigt hopknåpat. Som Anthropic påpekar har dessa primitiv överlevt långt mer fientlig uppmärksamhet än något du själv skulle bygga. Anpassa inneslutningen efter användaren också: en utvecklare som kan läsa och köra kod och en supportmedarbetare som inte kan är inte samma hotmodell, och ju kraftfullare verktygen är, desto snävare lådan.

Skyddsmekanism 8: Är agentens nätverkstrafik utåt begränsad och avgränsad efter förmåga? Detta är kontrollen som stoppade nätfiskeattacken ovan. Men en enkel lista över "tillåtna domäner" räcker inte på egen hand. Anthropic lärde sig den hårda vägen att angripare exfiltrerade filer via en tillåten domän genom att dirigera dem till sitt eget konto på den, så tänk på regler för utgående trafik som förmågebeviljanden (vad agenten får göra) snarare än bara en lista över adresser den får nå.

Skyddsmekanism 9: Loggas varje åtgärd på åtgärdsnivå för granskning? Du kan inte styra det du inte kan se. Varje åtgärd agenten utför, särskilt högriskåtgärderna, bör registreras med tillräcklig detaljrikedom för att rekonstruera vad som hände, vem eller vad som utlöste det och vad det rörde vid. Loggar på åtgärdsnivå är hur du fångar ett långsamt problem innan det blir en rubrik, och hur du skärper de andra åtta skyddsmekanismerna med tiden.

Hur ser den färdiga checklistan ut?

Här är de nio på ett ställe, var och en formulerad som ett ja eller nej du kan verifiera. Ett nej är en brist att åtgärda före lansering, inte en fotnot.

Lägg märke till formen. De första fyra är beslut du fattar om risk, de sista fem är kontroller du bygger in i miljön. De första fyra kan luras. De sista fem kan inte pratas ur att göra sitt jobb, vilket är varför de inte är förhandlingsbara ens när modellen är utmärkt.

Hur kör jag denna granskning mot en leverantörs agent?

Samma nio frågor fungerar lika bra på någon annans agent, och de är det snabbaste sättet att skilja en innesluten produkt från en självsäker demo. En demo bevisar att agenten fungerar en bra dag. Checklistan bevisar vad som händer en dålig dag.

Be leverantören besvara dessa på vanligt språk:

• Vilka av mina åtgärder kräver mänskligt godkännande innan de körs? En leverantör som inte kan namnge dem har inte betygsatt dem.
• Får agenten en egen identitet med åtkomst enligt minsta privilegium, eller använder den en delad nyckel in i mina system? Det andra svaret är en varningsflagga.
• Är den isolerad i en sandlåda, och vad kan den nå på nätverket? "Den kan nå internet" är inget svar.
• Loggas varje åtgärd, och kan jag se de loggarna? Om du inte kan granska den kan du inte styra den.
• Hur stor är skadeomfattningen om agenten luras? Det ärliga svaret är en lista över vad den kan röra vid, inte ett löfte om att den aldrig kommer att luras.

Om svaren är vaga, eller vilar helt på att "modellen sköter sig väl", är agenten inte i schack, oavsett hur bra demon såg ut. En bra leverantör har svaren redo, eftersom det är samma frågor de borde ha ställt sig själva.

Varför spelar detta roll just nu?

Eftersom klyftan mellan team som klarar denna granskning och team som hoppar över den är på väg att synas i siffrorna. Gartner förväntar sig att mer än 40% av agentbaserade AI-projekt kommer att läggas ner före slutet av 2027, med otillräckliga riskkontroller utpekade bland orsakerna, och förutspår att 25% av företagens generativa AI-applikationer år 2028 kommer att drabbas av minst fem mindre säkerhetsincidenter per år, upp från 9% år 2025. Skyddsmekanismer går från en konfigurationsinställning till ett budgeterat kontrollplan, och granskningen ovan är hur du håller dig på rätt sida av den förändringen.

Det uppmuntrande är att inget av detta är exotiskt. Koppla varje åtgärd till en riskbedömning och spärra det oåterkalleliga. Ge agenten en egen identitet med den minsta åtkomst den behöver, i en sandlåda, med nätverket inhägnat och varje åtgärd loggad. Håll den mänskliga spärren tillräckligt sällsynt för att människor fortfarande läser den. Gör det, och en angripare som slinker förbi ditt filter springer ändå in i en vägg av förmåga den aldrig fått tillgång till.

Om du vill ha dessa nio skyddsmekanismer byggda, verifierade och drivna åt dig innan din första agent går live, är det precis det arbete vi gör inne i andra företags system. Boka en kostnadsfri konsultation nedan så kör vi denna checklista mot din agent tillsammans.