Säkra AI-agentens behörigheter utanför prompten

En AI-agents behörigheter ska avgöras utanför prompten: genom dess identitet, en separat kontroll av verktygsanropet och åtkomstregler i tjänsten som tar emot det. Börja med läsrättigheter för en avgränsad uppgift. Ge skrivrättigheter bara när arbetet kräver dem och låt en tillfällig höjning upphöra när arbetet är klart.

En instruktion som säger ”ändra aldrig produktionsdata” hindrar inte i sig ett ändringsanrop. OWASP:s vägledning för AI-agenter och MCP beskriver varför tillståndsdialoger inte är en säkerhetsgräns mot en manipulerad agent. Den rekommenderar bland annat isolerad körning, begränsad utgående nätverkstrafik och granskade MCP-servrar.

Avgränsa uppdraget innan agenten får åtkomst

Skriv ned vad agenten ska läsa, vilket resultat den får skapa och vilka system som behövs. Ange resurs, datamängd, tillåten åtgärd och ansvarig ägare för varje åtkomst. En agent som sammanfattar ärenden behöver exempelvis kunna läsa godkända ärenden, men behöver inte kunna radera dem eller ändra användares roller.

Inventeringen måste omfatta hela kedjan: agent, verktyg, eventuell MCP-server och bakomliggande API. Ett verktyg med ett begränsat syfte kan ha bredare behörighet i nästa led. Bedöm därför vad kombinationen av roller och anslutningar faktiskt tillåter, inte bara vad agentens egen konfiguration visar.

Flytta fasta beslut till vanlig programlogik. Om ett anrop alltid ska nekas för en viss resurs ska kod eller åtkomstpolicy fatta beslutet. Modellen kan välja mellan godkända arbetsmoment, men ska inte själv avgöra vilka säkerhetsregler som gäller för dem.

Ge agenten en egen identitet och separata roller

En separat agentidentitet får läsa ett avgränsat ärende, medan skrivrättigheten hålls åtskild.

Skapa en unik identitet för agenten med en namngiven ägare. Låt den inte använda en utvecklares personliga inloggning eller dela en generell nyckel med andra agenter. Microsofts mönster för minsta möjliga agentbehörighet beskriver uppgiftsavgränsade roller, listor över tillåtna verktyg och åtgärder, tidsbegränsad höjning, spårbarhet och testad återkallelse.

En rollindelning i ett ärendesystem kan se ut så här. Det är ett villkorat exempel; resurser och åtgärder måste anpassas till organisationens egna API:er:

Läsroll: får hämta ärenden i en godkänd kö och läsa de fält som uppgiften kräver. Den får inte skapa, exportera eller radera ärenden.
Skrivroll: får skapa eller uppdatera ärenden i samma kö. Den ger inte rätt att ändra behörigheter, göra massändringar eller radera data.
Tidsbegränsad höjning: ger rätt till en angiven skrivåtgärd mot en angiven resurs efter separat godkännande och upphör efter arbetsflödet.

Utfärda en kortlivad token med rätt mottagare och snävt omfång för uppgiften. Verktyget och mål-API:et ska kontrollera identitet, roll och resurs vid anropet; ett godkännande i agentens egen planering räcker inte. Låt inte agenten läsa långlivade produktionsnycklar ur prompten, processmiljön eller lokala filer.

Låt en verktygslista styra varje anrop

Definiera vilka verktyg och åtgärder varje roll får använda. En läsagent kan tillåtas att hämta ett ärende men ska nekas ett anrop som uppdaterar samma ärende, även om båda funktionerna finns i samma integration. Kontrollera också anropets argument: målresurs, begärd åtgärd och eventuell destinationsadress.

Placera kontrollen i en komponent som agenten inte kan ändra, exempelvis framför verktygsanropen, och låt den mottagande tjänsten pröva sina egna rättigheter. Versionshantera policyn och låt en ansvarig granska ändringar. Ett nytt verktyg eller en ny MCP-server ska kräva ett uttryckligt beslut om åtkomst i stället för att automatiskt ärva befintliga rättigheter.

Den gränsen behövs också vid promptinjektion via agentens verktyg. Innehåll som agenten läser kan påverka vilken åtgärd den begär, medan den separata kontrollen avgör om åtgärden får utföras.

Isolera körningen och begränsa nätverket

Kör agenten och dess lokala verktyg i en avgränsad miljö utan monterad hemkatalog eller produktionshemligheter. Begränsa filåtkomsten till det uppgiften kräver. Kontrollera om isoleringen även omfattar filverktyg och MCP-servrar; ett skydd som bara gäller skalkommandon lämnar andra vägar öppna.

Tillåt utgående trafik enbart till tjänster som arbetsflödet behöver. Om agenten kan läsa interna uppgifter och samtidigt nå valfria externa adresser kan en skadlig instruktion i ett ärende, en webbsida eller ett verktygssvar leda till dataläckage. Granska därför varje anslutningsserver som körbar kod: vem som underhåller den, vilka rättigheter den begär och vilka nätverksmål den kan nå.

Knyt mänskligt godkännande till den faktiska åtgärden

Kräv mänskligt godkännande vid åtgärder som är svåra att ta tillbaka, till exempel driftsättning, radering, externa utskick och ändring av behörigheter. Visa den faktiska åtgärden, målresursen och argumenten. Ett allmänt godkännande av agentens plan ger inte granskaren samma möjlighet att upptäcka om ett senare anrop har bytt mål.

Bind beslutet till just det anrop som granskaren såg och utfärda först därefter den tillfälliga behörighet som behövs. Om argumenten ändras ska ett nytt beslut krävas. Behåll åtkomstkontrollen även efter godkännandet: människan avgör om arbetet ska göras, medan tjänsten begränsar vad agenten tekniskt kan utföra.

Logga, stoppa och pröva hela kedjan

Agentens åtkomst till ärendesystemet stoppas medan tidigare verktygsanrop finns kvar för granskning.

En stoppknapp måste hindra nya åtgärder även om agenten redan har fått en token. AWS vägledning för säker agentdrift rekommenderar snabb avstängning eller säkert läge vid hög risk samt en plan för hur verksamheten fortsätter medan agentsystemet är avstängt. Utse i förväg vem som får utlösa stoppet.

Logga varje verktygsanrop med agentidentitet, initierande användare, roll, effektivt behörighetsomfång, målresurs, beslut och ett korrelations-ID som följer anropet till mål-API:et. Skriv loggen till en plats som agenten inte kan ändra och undvik hemliga värden. Registrera både godkända och nekade försök; agentens slutliga svar visar inte vilka anrop den försökte göra.

Pröva före driftsättning att stoppet hindrar nya anrop, att utfärdade token återkallas eller blockeras enligt den valda lösningen och att mål-API:et verkligen nekar otillåtna åtgärder. Om en token inte kan återkallas omedelbart måste åtkomstkontrollen kunna neka den medan den fortfarande är giltig. Återaktivering ska kräva ett medvetet beslut efter att orsaken har hanterats.