JumpCloud ramme AI-agent identitetsstyring

En AI-agent, der henter data fra et CRM, opretter tickets i et supportsystem eller trigger workflows i en produktionslinje, opfører sig identitetsmæssigt som en medarbejder. Den logger ind, den har rettigheder, og den efterlader spor i loggen. Forskellen er, at den ofte er sat op i en fart, af en udvikler der bare ville have en proof of concept til at virke, og aldrig fik den registreret nogen steder som en rigtig konto.

Det er den grundlæggende udfordring: agenter breder sig hurtigere, end organisationerne kan styre dem. Vi ser det samme mønster hos danske virksomheder, vi arbejder med. En afdeling bygger en agent til at automatisere en arbejdsgang, den virker godt, og inden længe har tre andre teams kopieret ideen med deres egne varianter, hver med sit eget sæt adgangsnøgler og ingen central oversigt over, hvem der egentlig kan hvad.

Problemet vokser, fordi agenter ofte får bredere adgang, end opgaven kræver, simpelthen fordi det er hurtigere at give fuld adgang end at afgrænse den præcist. Når en agent har adgang til et helt datalager for at løse en enkelt opgave, er den samtidig en indgang til hele det lager, hvis noget går galt eller nogen misbruger den.

**TL;DR:** Rammen går fra at finde alle agenter, over at registrere dem med en navngiven ejer og minimale rettigheder uden faste nøgler, til løbende at overvåge deres adfærd.

JumpClouds model bygger på en logisk rækkefølge, som de fleste sikkerhedsrammer for identiteter følger, men som sjældent er blevet anvendt systematisk på agenter før nu.

Første trin er opdagelse. Man kan ikke styre det, man ikke ved eksisterer, og de fleste organisationer har ingen samlet liste over deres agenter. De findes spredt i cloud-konsoller, i CI/CD-pipelines, i chatbot-platforme og i interne scripts, ofte oprettet af enkeltpersoner uden at gå gennem en central proces. Opdagelsesfasen handler om at kortlægge dem alle, uanset hvor de bor.

Andet trin er registrering. Hver agent skal registreres som en formel identitet, på samme måde som en ny medarbejder får en personalesag. Det centrale krav her er en navngiven ejer, en konkret person og ikke et team eller en afdeling, der har ansvaret for agenten fra den dag, den sættes i drift.

Tredje trin er adgangsstyring efter mindste privilegium og uden stående legitimationsoplysninger. Agenten får kun adgang til præcis det, den skal bruge til den konkrete opgave, og den henter midlertidige, tidsbegrænsede adgangsnøgler i stedet for at ligge inde med faste nøgler, den kan bruge for evigt.

Fjerde trin er tilsyn, altså løbende overvågning af, hvordan agenterne rent faktisk opfører sig, når de er sat i drift. En agent kan sagtens starte med korrekt afgrænsede rettigheder og senere blive misbrugt eller manipuleret til at gøre noget andet end det, den var tiltænkt. Tilsyn er det, der fanger den type afvigelse, før den bliver et reelt problem.

Det mest praktiske og samtidig mest oversete princip i rammen er kravet om en navngiven, menneskelig ejer per agent. Årsagen er enkel: når en agent opfører sig mærkeligt, sender for mange forespørgsler, tilgår data den ikke plejer at røre ved, eller pludselig fejler i stor skala, skal der være nogen, der bliver ringet op klokken to om natten. Uden en navngiven ejer bliver ansvaret diffust, og en diffus ansvarsfordeling betyder i praksis, at ingen reagerer, før skaden er sket.

Mindste privilegium og navngivet ejerskab løser samme problem fra hver sin side. Mindste privilegium begrænser, hvor stor skaden kan blive, hvis en agent bliver kompromitteret eller går amok. Navngivet ejerskab sikrer, at der er nogen til at opdage og rette fejlen, når den sker.

For en virksomhed, der allerede har agenter i produktion, er den vigtigste indsigt, at gabet mellem antal og styring sjældent lukkes med et enkelt værktøjskøb. Det kræver en proces, der starter med at finde ud af, hvad man rent faktisk har kørende.

Det mest effektive første skridt er en inventarrunde: gå gennem cloud-konti, integrationer, automatiseringsplatforme og interne udviklingsmiljøer, og lav en liste over alle agenter, der har adgang til data eller systemer. De fleste organisationer bliver overraskede over, hvor mange de finder, som ingen længere husker formålet med.

Dernæst er det afgørende at knytte hver agent til en navngiven ejer, selv hvis det betyder at genindføre et krav om, at ingen agent må sættes i drift uden en ansvarlig person tilknyttet fra dag ét. Det er en organisatorisk beslutning lige så meget som en teknisk, og den skal håndhæves fremadrettet, ikke kun anvendes retroaktivt.

Hos Agent Enterprise, som jeg selv driver agentflåden for, lærte vi det på den hårde måde. En agent fik adgang til hele kundedatabasen for at løse én afgrænset opgave, fordi det var hurtigere end at skære adgangen til, og det tog os en eftermiddag at spore, hvem der egentlig havde sat den op sådan. Siden har ingen agent hos os fået adgang til noget, før den har en navngiven ejer og en rolle, der er skåret til den konkrete opgave, ikke bredere.

Den sidste del af opgaven er at etablere løbende overvågning, så adgangsrettigheder og adfærd ikke bare bliver sat rigtigt en gang og glemt. Agenter ændrer sig, opgaverne ændrer sig, og de systemer, de har adgang til, ændrer sig. Styring af agent-identiteter er ikke et projekt med en slutdato, men en driftsopgave på linje med resten af it-sikkerheden.