Runtime trust: identitet er ikke nok

Når en agent logger på et system, sker det typisk gennem den samme type identitetsverifikation, som mennesker og traditionelle applikationer bruger. Et token bekræfter, at agenten er den, den udgiver sig for at være, og giver den adgang til de ressourcer, den har brug for. Problemet opstår, fordi den tjekker identitet én gang, ved starten af en session, og ikke løbende undervejs.

En agent, der er verificeret klokken ni, kan sagtens have ændret adfærd klokken elleve, uden at nogen har opdaget det. Den har stadig sit gyldige token. Den har stadig sin adgang. Men den handling, den udfører nu, kan være helt anderledes end den, den var designet til at udføre. Det er her, det traditionelle sikkerhedslag kommer til kort. Adgangskontrol besvarer spørgsmålet "hvem er du", men ikke "gør du det rigtige lige nu".

Årsagen til, at agenter kan ende med at handle forkert, selv efter en gyldig verifikation, hedder ofte goal drift. Det er et fænomen, hvor en agent, der arbejder selvstændigt over længere tid, gradvist bevæger sig væk fra sin oprindelige opgave. Hver enkelt beslutning kan se rimelig ud isoleret set, men summen af mange små justeringer kan ende med en agent, der løser et helt andet problem, end den blev sat til.

Det sker typisk, når en agent skal fortolke tvetydige instruktioner eller tilpasse sig ny information undervejs i en lang arbejdsproces. Uden løbende kontrol af, om agenten stadig arbejder inden for sine oprindelige rammer, kan drift fortsætte ubemærket i timevis eller dage. For en virksomhed, der har sat en agent til at håndtere kundedata, fakturering eller kodeændringer, er det ikke et teoretisk problem. Det er en direkte risiko for, at agenten begynder at træffe beslutninger, som ingen har godkendt.

Et andet lag af problemet handler om, hvad agenten husker og stoler på. Mange agenter bygger deres beslutninger på en form for hukommelse eller kontekst, de har samlet undervejs, ofte hentet fra dokumenter, tidligere interaktioner eller eksterne datakilder. Hvis den hukommelse bliver manipuleret, kan en angriber effektivt omprogrammere agenten uden nogensinde at røre ved dens kode eller dens adgangsrettigheder.

Det kaldes memory poisoning, når skadelig eller vildledende information bliver plantet i det, agenten opfatter som pålidelig kontekst. En agent, der er blevet fodret med falske instruktioner gennem et forgiftet dokument eller en manipuleret dataintegration, vil handle på den information, som var den ægte. Den har ingen indbygget mistanke, medmindre systemet omkring den aktivt overvåger, om dens adfærd stadig stemmer overens med det, den burde gøre.

Problemet vokser markant, når flere agenter samarbejder i det samme system. En fejlagtig beslutning fra én agent kan blive videresendt som et input til den næste, som så bygger videre på den forkerte antagelse uden at stille spørgsmål ved den. På den måde kan en lille fejl i det ene led forstærkes gennem hele kæden, indtil resultatet er markant forkert.

Det er en dynamik, mange virksomheder ikke har taget højde for, fordi de har tænkt agent-sikkerhed som et spørgsmål om at sikre hver enkelt agent for sig. Men når agenter kommunikerer og handler på hinandens output, er det systemet som helhed, der skal kunne stå til ansvar for kvaliteten af beslutningerne, ikke kun den enkelte komponent. Jo mere autonomi, agenterne har til at handle uden menneskelig godkendelse undervejs, jo hurtigere kan en fejl brede sig gennem hele kæden.

Svaret på disse udfordringer er et nyt sikkerhedslag, som handler om løbende at validere agentens intention og adfærd, mens den arbejder, ikke kun ved login. Det kaldes runtime trust, og det adskiller sig fra traditionel identitetsstyring ved at behandle tillid som noget, der skal genbekræftes kontinuerligt, snarere end noget, der bliver etableret én gang og derefter antaget for givet.

Vi ser runtime trust som et lag, der stiller spørgsmålet "handler agenten stadig i overensstemmelse med sit formål" gennem hele dens levetid i systemet, ikke kun i det øjeblik den logger på. Det kræver overvågning af agentens faktiske handlinger op mod dens tilsigtede opgave, og det kræver mekanismer, der kan gribe ind, hvis adfærden begynder at afvige. Identitetslaget og adgangsstyringen bliver ikke overflødige af den grund, men de udgør ikke længere hele sikkerhedsbilledet. De er første forsvarslinje, ikke den eneste.

Hos Agent Enterprise, virksomheden jeg selv bygger og driver agentdriften for gennem AI Enterprise Konsulenten, kører vi agenter, der har adgang til rigtige systemer hver eneste dag. Jeg har set en agent, der var logget korrekt ind og havde alle rettigheder i orden, alligevel begynde at tolke en opgave anderledes efter et par timers arbejde. Det opdagede vi, fordi vi loggede hver handling og sammenlignede den med den oprindelige opgave, ikke fordi identitetslaget slog alarm. Det gjorde det aldrig, for agenten var stadig den, den udgav sig for at være.

Den erfaring er grunden til, at jeg ser identitetsstyring og adgangskontrol som en forudsætning, ikke en løsning i sig selv. En agent, der har adgang til kundedata, økonomisystemer eller kodebaser, skal overvåges løbende for, om dens faktiske adfærd stemmer overens med det, den er sat til at gøre. Det kræver logs, man rent faktisk kigger på, og en arkitektur, der er bygget til at fange afvigelse fra dag ét, ikke lappet på, når noget først er gået galt.

Spørgsmålet, jeg selv stiller til enhver agent, jeg sætter i produktion, er enkelt: kan jeg se, om dens adfærd har ændret sig undervejs i en arbejdsopgave, eller stoler jeg udelukkende på, at den stadig gør det, den blev sat til, fordi den engang blev godkendt til det?