AI-utvecklingen skapar fantastiska möjligheter, men den skapar också mycket oro. En fråga som ofta dyker upp är om man bör tillåta att AI-agenter får tillgång till interna resurser såsom data och tjänster. Inte sällan besvaras den frågan med ett rungande ”JA” av vissa, och med ett lika självsäkert “ABSOLUT INTE” av andra.

Det rätta svaret är både enklare och mer komplicerat än båda alternativen. Allt beror, som med så mycket annat, på hur vi gör när vi ger AI-agenter tillåtelse att använda våra interna resurser. Så länge som vi gör det på ett säkert sätt utgör AI-baserade agenter inte ett större hot än andra klienter. Men om vi slarvar och tar genvägar riskerar vi att skapa problem med säkerheten. Det är å andra sidan inget som är unikt för AI-agenter.

Men låt oss börja med att reda ut begreppen.

Vad särskiljer en AI-agent?

Även om AI-agenter är en ny typ av agenter så handlar det, precis som tidigare, om att de får tillgång till våra interna tjänster (exempelvis ett API). Att lägga till en klient, till exempel för att integrera med en ny tredje-part innebär alltid en risk, oavsett om det involverar AI eller inte. Det handlar i grunden om samma frågor som alltid: arkitektur, drift, åtkomst och ansvar.

Det som gör AI-agenter speciella är att de är mindre förutsägbara, de är inte statisk programmerade på samma sätt som en klassisk API klient för systemintegrationer. Vi vet helt enkelt inte på förhand exakt hur den kommer att agera för att lösa sin uppgift. På så sätt liknar de mer en kreativ mänsklig användare. Eftersom AI-agenten är delvis eller helt automatiserad kan den agera utan att en människa kan kontrollera exakt vad den gör. Potentiellt sett kan den utforska alla funktioner och all data den kan nå. På så sätt påminner AI-agenter om en angripare som tagit över ett konto, vilket kan verka skrämmande.

En annan viktig aspekt är att agenter ofta kör på uppdrag av en mänsklig användare och då ska de inte klassas som systemintegrationer, som ges en generell system-behörighet. Detta gäller även om de opererar utan att användaren godkänner varje steg, eftersom användaren har delegerat sin behörighet till agenten att agera för dennes räkning. Här vill vi oftast ha fortsatt god spårbarhet över att det är agenten som agerar på uppdrag av användaren.

Vilka skydd behöver vi?

Hur hanterar vi säkerheten för en agent med delegerad behörighet och som mer eller mindre självständigt löser en uppgift? Svaret är detsamma som för alla klienter som får tillgång till våra data och tjänster; med väletablerade säkerhetsprinciper och mönster så som Secure By Design, Defense in Depth, Zero Trust och Least Privilege.

En stark lösning kräver att API:et, oavsett om klienten är AI-baserad eller ej, säkerställer finmaskig behörighetskontroll. Att försöka lösa bristande behörighetskontroll hos resursägaren på server-sidan (APIet) med restriktioner hos klienten, kommer sannolikt inte fungera. Speciellt inte för en så flexibel och oförutsägbar klient som en AI-agent.

Ett vanligt misstag är att man utgår ifrån en lång lista över saker som klienten inte får göra, en “deny-list”. Det är en stökig och osäker lösning som kräver att vi förutser alla tänkbara problem som agenten kan orsaka. Otaliga penetrationstester har visat faran med den metoden. Istället bör vi skapa en “allow-list”, det vill säga en strikt uppsättning rättigheter där vi tillämpar Least Privilege-principen. En allow-list kommer alltid att vara starkare än en deny-list.

Det betyder inte att deny-lists, såsom så kallade Guardrails, bör undvikas helt. Med Guardrails försöker man förbjuda specifik input för en extremt öppen och flexibel domän (en LLM). Man kan likna detta vid hur svårt det är för anti-virusscanners att i tid detektera nya varianter av virus. Men på samma sätt som vi trots allt bör ha anti-virusscanners aktiva så bör vi använda Guardrails. Det är dock viktigt att inse vilket slags skydd de faktiskt erbjuder, och att de aldrig ersätter en korrekt behörighetskontroll på server-sidan när det gäller åtkomst till interna data.

Så hur implementerar vi AI-lösningar på ett säkert sätt?

Industristandard för att hantera den här typen av scenarier, med säker tillgång till interna resurser för olika typer av klienter, är OAuth. För AI-agenter (LLM:er) etableras just nu MCP som standard, vilken är integrerad med OAuth. För vidare läsning och teknisk förklaring rekommenderas:

https://curity.io/resources/learn/design-mcp-authorization-apis

https://genai.owasp.org/llm-top-10

Och för mer läsning om Secure By Design som koncept och API säkerhet, finns material på Omegapoints säkerhetsblogg.