Seks kontrolgates skal sikre AI-agenter

De fleste agent-arkitekturer, jeg møder i produktion i dag, har en solid frontdør. Man verificerer, at agenten er den, den udgiver sig for at være, tildeler den et token eller en nøgle, og lader den derefter operere inden for de rettigheder, tokenet giver. Det er nødvendigt, men det er kontrol af identitet, ikke kontrol af adfærd. Når agenten først er inde, er der i mange af de opsætninger, jeg har rettet på, intet, der løbende vurderer, om dens handlinger stadig giver mening i forhold til opgaven, dens historik eller den kontekst, den arbejder i.

Det er her forskellen mellem statisk og dynamisk tillid bliver afgørende for mig. Statisk tillid er et engangstjek: login, token, adgang. Dynamisk tillid er en løbende vurdering: er denne forespørgsel konsistent med, hvad denne agent plejer at gøre? Trækker den på data, den ikke har brug for til denne opgave? Er der tegn på, at dens instruktioner er blevet manipuleret undervejs? Uden det andet lag er selv den bedst implementerede autentificering kun en dør, der lukker sig bag angriberen, ikke foran ham.

LiteLLM er en udbredt proxy-lags-komponent, som mange agent-stakke, inklusive nogle af dem jeg selv har sat op, bruger til at rute kald mellem forskellige sprogmodeller og holde styr på nøgler, kvoter og logning ét sted. Det gør den til et attraktivt mål, fordi den sidder centralt: kompromitterer man proxyen, kompromitterer man i praksis adgangen til alt, hvad der går igennem den. En dokumenteret sårbarhed i komponenten blev udnyttet til netop at demonstrere, at en agent kan operere fuldt autentificeret gennem systemet, mens selve trafikken eller konfigurationen bag proxyen bliver manipuleret uden at nogen af de almindelige identitetstjek slår ud.

Jeg har selv haft en lignende oplevelse hos en international klient med drift i flere lande, jeg ikke navngiver: en af deres agenter blev ved med at bestå hver eneste autentificeringskontrol, mens den i baggrunden trak på et datasæt, den ikke længere skulle have adgang til, fordi opgaven var ændret ugen før. Ingen alarm gik af, fordi alarmerne kun kiggede på login, ikke på adfærd. Jeg har ikke et præcist tal på, hvor længe det stod på, men det var længe nok til at gøre indtryk. Pointen med LiteLLM-sagen er ikke, at komponenten er særligt svag. Pointen er, at proxy-laget og gateway-laget typisk er bygget til at håndtere routing og rettigheder, ikke til at opdage adfærdsmæssige afvigelser. Når et sådant lag bliver kompromitteret, arver angriberen den tillid, systemet allerede har givet den legitime agent.

Min løsning er ikke at stramme gatewayen yderligere. Det er at lagdele kontrollen, så et enkelt kompromitteret punkt ikke giver fuld adgang. Jeg bruger en model med seks kontrolgates, der hver især dækker et sted, hvor tillid kan gå tabt, og som skal gennemløbes i en bestemt rækkefølge, fordi de bygger på hinanden. Springer man et trin over, mister de efterfølgende trin en del af deres værdi, fordi de forudsætter, at fundamentet allerede er på plads.

Først kommer inventar og identitet: jeg skal kunne se og navngive hver eneste agent, der kører, inklusive dem, jeg selv driver for Agent Enterprise. Derefter kortlivede adgangsnøgler og sporbar telemetri, så enhver handling kan spores tilbage til en bestemt agent-instans og et bestemt formål. Derefter runtime-håndhævelse med en adfærdsbaseline og en reel kill-switch, der kan slukke en agent, der opfører sig unormalt, uden at det kræver en manuel undersøgelse først. De tre lag hænger sammen: uden identitet ved jeg ikke, hvem der handler forkert. Uden telemetri kan jeg ikke bevise det. Uden håndhævelse kan jeg ikke stoppe det i tide.

Det lyder elementært, men de fleste organisationer, jeg har set indefra, kan i praksis ikke svare præcist på, hvor mange agenter der kører, hvad de har adgang til, og hvem der ejer dem. Agenter bliver ofte oprettet ad hoc af enkelte teams, genbruger delte nøgler, eller arver rettigheder fra en skabelon uden individuel gennemgang. Det skaber et landskab, hvor identiteten er kollektiv snarere end individuel, og dermed umuligt at holde ansvarlig.

Da jeg byggede agent-driften hos Agent Enterprise, var det første, jeg gjorde, at lave et fuldstændigt inventar, hvor hver agent fik sin egen distinkte identitet, adskilt fra de andre agenter og fra mig selv som den, der satte dem op. Det er kedeligt administrativt arbejde, men det er forudsætningen for alt det følgende. Jeg kan ikke bygge en adfærdsbaseline for en agent, jeg ikke kan identificere entydigt.

Næste lag handler om, hvor længe en agent har adgang til noget, og om jeg kan se, hvad den brugte adgangen til. Langtidsholdbare nøgler, der ikke udløber, er et af de mest almindelige svage punkter, jeg støder på i agent-arkitekturer i dag, fordi en kompromitteret nøgle så giver vedvarende adgang i stedet for et kort tidsvindue. Kortlivede credentials, der fornyes automatisk og kun gælder for den konkrete opgave, begrænser skaden markant, hvis noget alligevel går galt.

Det kobler jeg altid med telemetri, der er attribuerbar helt ned til den enkelte agent-instans og handling, ikke bare til en delt tjenestekonto. Uden det kan jeg ikke svare på det spørgsmål, en revision eller en hændelsesundersøgelse altid stiller: hvad gjorde denne agent, hvornår, og hvorfor havde den adgang til det?

Det sidste lag er der, hvor systemet reelt griber ind. En adfærdsbaseline beskriver, hvad normal drift ser ud som for en given agent: hvilke systemer den typisk taler med, hvilke datamængder den typisk trækker, hvilke mønstre der er normale for dens opgave. Når en agent bevæger sig markant væk fra den baseline, uden at det er begrundet i en legitim ny opgave, er det et signal, jeg vil have skal udløse en automatisk reaktion, ikke bare en log-post, jeg læser dagen efter.

Det kræver en kill-switch, der faktisk virker i praksis: en mekanisme, der kan sætte en agents adgang på pause øjeblikkeligt, uden at det kræver godkendelse fra flere niveauer først. Hos Agent Enterprise har jeg selv oplevet, hvor meget forskel det gør at kunne slukke en agent midt om natten uden at vente på et møde. Gennem mine engagementer i større, internationale organisationer har jeg til gengæld set for mange steder, hvor alarmering var på plads, men den hurtige, ubureaukratiske handlemulighed manglede, så alarmen ikke var noget værd i det øjeblik, det talte.