AI-agenter blir smartere og deres angrepsflate blir større

Øyeblikket AI-agenter begynte å booke møter, kjøre kode og bla på nettet på vegne av deg, skiftet sikkerhetskonversasjonen. Ikke sakte, men over natten.

Hva som tidligere var et innhegnet, forutsigbart programvaresystem ble noe som grunner, planlegger og tar handlinger over verktøy og API-er det knapt visste eksisterte for et år siden.

Dette er virkelig spennende, og det er også virkelig skremmende, fordi angrepsflaten som følger med denne autonomien er enorm, og de fleste organisasjoner er bare begynt å forstå hva det betyr å la agenter inn i deres infrastruktur.

Fra Chatbots til Operatører

Det opprinnelige løftet om AI var enkelt: stille et spørsmål, få et svar. Dette er fortsatt sant for de fleste forbrukerinteraksjoner, men det er ikke hva som skjer i bedriftsinstallasjoner lenger. I dag håndteres agentene kredensialer, API-nøkler og evnen til å slette, opprette og annotere data, samt ta virkelig handling innen systemer som har virkelige konsekvenser.

Skiftet skjedde raskt. På mindre enn to år gikk AI-agenter fra å være tekstgenereringer til å la oss kjøre glatte, multi-agentsystemer. De leser e-post, utløser arbeidsflyter, spør databases og i noen tilfeller håndterer andre agenter under dem. Denne tilgangen var tidligere å kreve en omfattende anskaffelsesprosess og en menneskelig i løkken. Nå er det en konfigurasjonsfil og noen API-oppkall

Mer Tilgang Betyr Mer Eksponering

Tradisjonelle programvareangrep har en noe forutsigbar profil. Det finnes en kjent inngangspunkt, en kjent sårbarhet, en kjent patch. AI-agenter bryter denne modellen fordi de er dynamiske av design. De følger ikke en statisk kodevei. De grunner over hva de skal gjøre neste, hvilket betyr at deres atferd er hardere å forutsi og mye harder å granske etterpå.

Denne uforutsigbarheten er nyttig for å få arbeid gjort. Det er også en fordel for noen som prøver å utnytte systemet. Når en agent kan bestemme, midt i en oppgave, å ringe en ekstern API eller trekke inn en tredjepartsverktøy, finnes det ingen ren periferi å forsvare.

Sikkerhetsteam er vant til å beskytte kjente overflater og overvåke Kubernetes-kostnader. Agenter fortsetter å oppdage nye overflater og utnyttelser, og ingen kartlegger dem i sanntid. Før du vet det, kan noen kapre kredensialene og få kontroll over hele AI-“organismen” med ett trekk.

Promptinjeksjon Er Det Nye SQL-injeksjon

Hvis det er ett angrepsvektor som sikkerhetsforskere stadig kommer tilbake til, er det promptinjeksjon. Idéen er enkel: i stedet for å utnytte en kodevulnerabilitet, manipulerer en angriper instruksjonene en agent mottar gjennom sine inndata. En skadelig instruksjon innbettet i en nettside, et dokument eller selv en e-post kan omdirigere hva agenten gjør neste.

Hva gjør dette spesielt skarpt er at agenter ofte gjør akkurat hva de blir bedt om. De prosesserer innhold fra nettet, fra brukermeldinger, fra tredjepartsverktøy. Noe av dette innholdet er en potensiell injeksjonsflate. En agent som leser et kompromittert dokument og deretter gjør API-oppkall basert på innholdet, er blitt kapret, og det vil sannsynligvis ikke logge noe som gjør årsakssammenhengen åpenbar.

Forsvarsmekanismene her er reelle, men ufullstendige. Sandboksing av agenthandling, begrensning av hvilke verktøy en agent kan ringe i visse sammenhenger, og bygging av menneskelige sjekkpunkter inn i høyrisk-arbeidsflyter, reduserer risikoen. De eliminerer den ikke. Og de fleste organisasjonene har ikke implementert selv grunnleggende ting ennå.

Tillitsproblemet Innenfor Multi-Agent-Systemer

Multi-agent-systemer introduserer et kompleksitetslag som er lett å undervurdere. Når en agent koordinerer flere andre, er det en tillitshierarki i spill. Koordinatoren overfører instruksjoner nedover, og underagenter følger dem. Hvis koordinator blir kompromittert, hver agent under den er effektivt kompromittert også, og skadeområdet blir stort meget raskt.

Det er også problemet med over-tilgang. Agenter får ofte tildelt mer tilgang enn de trenger fordi det er enklere å gi brede tillatelser på forhånd enn å finjustere dem iterativt. En forskningsagent trenger ikke skrive-tilgang til en produksjonsdatabase.

En planleggingsagent trenger ikke tilgang til finansielle opplysninger. Ja, det føles trygt å ha alt sammenkoblet, men det er simpelthen for risikabelt å se noen ikke-diminuerende avkastning. Men linjene blir uklare i praksis, og minimaltillgangsprinsipper som fungerer bra i teorien, blir stille og rolig forkastet i hastigheten til å levere.

Hva Rimelig Sikkerhet Ser Ut Som Her

Det finnes ingen enkelt løsning som gjør agent-utplasseringer trygge. Dette er et lagdelt problem og det trenger et lagdelt svar. Organisasjoner som gjør dette bra, begynner ofte med tilgangskontroll: gi hver agent en definert, smal omfang og bygge gjennomgangstrinn inn i enhver handling som berører sensitive systemer eller eksterne tjenester.

Observasjon er like viktig som forebygging. Hvis en agent gjør noe uventet, teamene trenger en full sporingslogg over hva instruksjoner den mottok, hva verktøy den ringte, og hva den returnerte. De fleste loggingsoppsett er ikke bygget med denne type finhet i mente, og å bygge det inn fra starten er verdt friksjonen.

Adversarial testing er også underutnyttet. Red-teaming agenter, spesielt forsøk på å injisere skadelige instruksjoner og se hva som skjer, avdekker sårbarheter som statisk kodegjennomgang aldri vil fange. Det er ubehagelig å tenke på, men de som til slutt vil utnytte disse systemene, gjør det allerede. Å komme først er den eneste fornuftige bevegelsen.

Slutt tanker

AI-agenter vil bli en større del av hvordan organisasjoner opererer, og denne skiftet er allerede godt i gang. Sikkerhetskonversasjonen må holde tritt, og raskt. Risikoen er reell, angrepsvektorene er nye, og vinduet for å komme foran dem er smalner.

Å forstå trussellandskapet for autonome AI-systemer, er ikke lenger valgfritt. Det er en av de viktigste ting sikkerhets- og ingeniørteam kan gjøre nå, og klokken på å gjøre det riktige, har allerede startet.