AI-agenter bliver klogere og deres angrebsflade bliver større

Øjeblikket AI-agenter begyndte at booke møder, udføre kode og browse på nettet på dine vegne, skiftede sikkerhedssamtalen. Ikke langsomt, men i stedet over natten.

Hvad der tidligere var et indhegnet, forudsigeligt software-system blev til noget, der grunder, planlægger og tager handlinger på tværs af værktøjer og API’er, som det knap nok kendte eksistensen af for et år siden.

Det er virkelig spændende, og det er også virkelig skræmmende, fordi angrebsfladen, der følger med den autonomi, er enorm, og de fleste organisationer er kun lige begyndt at forstå, hvad det betyder at lade agenter ind i deres infrastruktur.

Fra chatbots til operatører

Det oprindelige løfte om AI var enkelt: stille et spørgsmål, få et svar. Det er stadig sandt for de fleste forbrugerinteraktioner, men det er ikke, hvad der sker i virksomhedsinstallationer længere. I dag bliver agenterne givet legitimationsoplysninger, API-nøgler og mulighed for at slette, oprette og annotere data, samt tage virkelige handlinger inden for systemer, der har virkelige konsekvenser.

Skiftet skete hurtigt. På mindre end to år gik AI-agenter fra at være tekstgenereringsværktøjer til at tillade os at køre glatte, multi-agentsætninger. De læser e-mails, udløser arbejdsgange, forespørger databaser og i visse tilfælde styrer andre agenter under dem. Den adgang, der tidligere krævede en længerevarende indkøbsproces og en menneskelig i løkken, er nu en konfigurationsfil og nogle få API-opkald

Mere adgang betyder mere eksponering

Traditionelle softwareangreb har en noget forudsigelig profil. Der er en kendt indgangspunkt, en kendt sårbarhed, en kendt patch. AI-agenter bryder denne model, fordi de er dynamiske af design. De følger ikke en statisk kodevej. De grunder om, hvad de skal gøre herefter, hvilket betyder, at deres adfærd er sværere at forudsige og meget sværere at gennemgå efterfølgende.

Denne uforudsigelighed er nyttig til at få arbejdet gjort. Det er også en fordel for enhver, der forsøger at udnytte systemet. Når en agent kan beslutte, midt i en opgave, at ringe til en ekstern API eller trække en tredjeparts-værktøj ind, er der ingen ren periferi at forsvare.

Sikkerhedsteams er vant til at beskytte kendte overflader og overvåge Kubernetes-omkostninger. Agenter opdager hele tiden nye overflader og udnyttelser, og ingen kortlægger dem i realtid. Før man ved af det, kan nogen kapre legitimationsoplysningerne og få kontrol over hele din AI-“organisme” med ét træk.

Prompt-injektion er det nye SQL-injektion

Hvis der er en angrebsvektor, som sikkerhedsforskere hele tiden vender tilbage til, er det prompt-injektion. Ideen er enkel: i stedet for at udnytte en kode-sårbarhed manipulerer en angriber de instruktioner, en agent modtager gennem dens indgange. En ondsindet instruktion indlejret i en webside, et dokument eller endda en e-mail kan omdirigere, hvad agenten gør herefter.

Hvad gør dette særligt skarpt, er, at agenter ofte gør præcis, hvad de bliver bedt om. De behandler indhold fra nettet, fra brugermeddelelser, fra tredjeparts-værktøjer. Ethvert af dette indhold er en potentiel injektionsoverflade. En agent, der læser et kompromitteret dokument og derefter foretager API-opkald baseret på dets indhold, er blevet kapret, og det logger sandsynligvis ikke noget, der gør årsagskæden åbenbar.

Det tillidsproblem inden for multi-agentsystemer

Multi-agentsystemer introducerer et lag af kompleksitet, der er let at undervurdere. Når en agent orkestrerer flere andre, er der en tillidshierarki på spil. Orkestratoren passerer instruktioner ned, og underagenter følger dem. Hvis denne orkestrator bliver kompromitteret, er hver agent under den effektivt kompromitteret, og skadens radius bliver stor meget hurtigt.

Der er også problemet med over-tildelegering. Agenter får ofte tildelt mere adgang, end de har brug for, fordi det er nemmere at give brede tilladelser fra starten end at finpudse dem iterativt. En forskningsagent har ikke brug for skriveadgang til en produktionsdatabase.

En planlægningsagent har ikke brug for adgang til finansielle optegnelser. Ja, det føles beroligende at have alt sammenkoblet, men det er simpelthen for risikabelt at se nogen ikke-formindskende afkast. Men grænserne bliver uklare i praksis, og minimaltilladelsesprincipper, der fungerer fint i teorien, bliver stille og roligt opgivet i hastværket med at sende noget ud.

Hvad rimelig sikkerhed ser ud som her

Der er ingen enkelt løsning, der gør agentinstallationer sikre. Det er et lagdelt problem, og det kræver en lagdelt respons. Organisationer, der gør det godt, tenderer til at starte med adgangskontroller: give hver agent en defineret, snæver omfang og bygge gennemgangstrin ind i enhver handling, der berører følsomme systemer eller eksterne tjenester.

Observabilitet betyder lige så meget som forebyggelse. Hvis en agent gør noget uventet, har teams brug for en fuld spor af, hvilke instruktioner den modtog, hvilke værktøjer den kaldte, og hvad den returnerede. De fleste logindstillinger er ikke bygget med den slags granularitet i mente, og at tilføje det efterfølgende er smertefuldt. At bygge det ind fra starten er værd at kæmpe for.

Adversarial testning er også underudnyttet. Red-teaming agenter, specifikt forsøger at injicere ondsindede instruktioner og se, hvad der sker, afslører sårbarheder, som statisk kodegennemgang aldrig vil fange. Det er ubehageligt at tænke på, men de mennesker, der vil forsøge at udnytte disse systemer, gør det allerede. At komme først er den eneste fornuftige bevægelse.

Endelige tanker

AI-agenter vil blive en større del af, hvordan organisationer opererer, og den skift er allerede godt i gang. Sikkerhedssamtalen må indhente, og hurtigt. Risikoen er reel, angrebsvektorerne er nyt, og vinduet for at komme foran dem er smallende.

At forstå trusselslandskabet for autonome AI-systemer er ikke længere valgfrit. Det er en af de vigtigste ting, sikkerheds- og ingeniørteams kan lave lige nu, og uret på at få det rigtigt har allerede startet.