AI-agenter har efterhånden adgang til de samme systemer som
AI-agenter har efterhånden adgang til de samme systemer som medarbejdere, ofte uden at nogen har defineret, hvem de egentlig er, eller hvad de må. Det er den kløft, sikkerhedsfirmaet Hush Security nu bygger en løsning til, efter en investering på 30 mio. dollar i frisk kapital.
Identitetsstyring
Fra promptfiltre til identitetsstyring af agenter
Den første bølge af AI-sikkerhed handlede om modellen selv: filtrere skadelige prompts, blokere farlige svar, teste om en chatbot kunne narres til at sige noget forkert. Jeg har brugt måneder på præcis den slags arbejde, og det giver stadig mening. Men det løser ikke det problem, jeg selv støder på, når en agent begynder at handle på egne vegne inde i et produktionssystem.
Det er den forskydning, Hush Securitys stifter og CEO, Micha Rave, peger på. Ifølge ham er sikkerhedsdiskussionen flyttet fra spørgsmålet om, hvorvidt en model kan sikres, til spørgsmålet om, hvem en agent egentlig er, og hvad den har lov til at gøre, i takt med at virksomheder ruller agenter ud i egentlig drift.
Det kan jeg nikke genkendende til. En agent, der henter data fra et CRM-system, opdaterer en database eller kalder en ekstern API, opfører sig funktionelt som en bruger med rettigheder. Problemet er, at de færreste virksomheder har taget stilling til, hvilken bruger den agent egentlig er. Jeg ser det samme mønster igen og igen: mange agenter deler én servicekonto med brede rettigheder, fordi det var den hurtigste vej til at få noget i drift. Det er bekvemt, lige indtil noget går galt, og ingen kan se, hvilken agent der gjorde hvad.
Hush Securitys pointe er, at sikkerhedsarbejdet skal flytte sig fra "er modellen sikker" til "hvem er denne agent, og hvad må den præcis gøre". Det er en afgørende linje at trække. Det er adgangen, ikke modellens svar, der forårsager den reelle skade, når noget går galt.
Identity Gateway
Identity Gateway: én identitet per agent, sporbar adgang
Produktet, den nye kapital finansierer, hedder Identity Gateway. Grundideen er enkel: hver AI-agent skal have sin egen identitet, ligesom en medarbejder har sit eget login, i stedet for at dele en fælles nøgle med ti andre agenter og integrationer.
Med en dedikeret identitet per agent bliver det muligt at sætte præcise rettigheder op: denne agent må læse fra ét system, men ikke skrive til et andet. Den kan hente kundedata til et svar, men ikke eksportere det i bulk. Adgangen bliver noget, man kan styre og indskrænke, i stedet for en åben ledningsforbindelse ind i virksomhedens systemer. Det er den samme tankegang, jeg selv bygger ind i de agentsetups, jeg sætter i drift.
Det giver også noget, mange virksomheder i dag ikke har: en brugbar log over, hvilken agent der gjorde hvad, hvornår. Uden individuelle identiteter er det stort set umuligt at rekonstruere en hændelse bagudrettet, fordi al trafikken ligger samlet under én delt konto. Med en gateway, der styrer adgangen centralt, bliver det muligt at se mønstre, opdage afvigelser og lukke adgang for én bestemt agent, uden at det rammer resten af driften.
Timing
Hvorfor timingen giver mening lige nu
Det er ikke tilfældigt, at investorer skyder penge i den slags infrastruktur netop nu. Antallet af AI-agenter i produktion er vokset markant hurtigere, end de fleste virksomheders sikkerhedsarkitektur har fulgt med til. Analysehuse har peget på, at agentisk AI er et af de områder, virksomheder investerer mest aggressivt i over det kommende år, samtidig med at governance omkring den samme teknologi typisk halter bagefter udrulningen.
Det mønster blev tydeligt demonstreret af et angreb der brød ud af sin afgrænsning hos Hugging Face, som viste, hvor sårbare AI-systemer kan være, når adgangsstyringen ikke er på plads. Hændelsen ramte flere organisationer på tværs af en delt infrastruktur og illustrerer præcis den type risiko, en identitetsbaseret adgangsmodel er designet til at begrænse: når en agent kun kan gøre det, dens identitet tillader, bliver skadesomfanget af en fejl eller et angreb markant mindre.
Det er også værd at bemærke, at problemet ikke er unikt for én leverandør eller ét produkt. Flere aktører i branchen arbejder parallelt med at bygge kontrollag omkring agenters adgang, fra gateway-løsninger til rammer for, hvordan man overhovedet definerer et sikkert agent-setup i produktion. Hush Security er ét bud på løsningen, ikke det eneste.
Jo tidligere man definerer, hvilke systemer en agent må tale med, og under hvilken identitet, jo billigere er det at rette, hvis noget ændrer sig.
Praksis
Hvad det betyder for danske virksomheder med agenter i drift
For de fleste danske virksomheder, der er i gang med at rulle AI-agenter ud, er identitetsstyring sjældent det første, man tænker på. Fokus ligger typisk på, om agenten løser opgaven korrekt, ikke på hvilken konto den kører under, eller hvor bredt dens adgang reelt strækker sig.
Det er en forståelig prioritering tidligt i et projekt, men den bliver dyr at rette op på senere. Jeg ser det samme mønster igen og igen hos AI Enterprise: spørgsmålet om identitet og adgang kommer for sent ind i projekter, typisk først når en agent skal i egentlig produktion og røre ved kundedata eller betalingssystemer. Jo tidligere man definerer, hvilke systemer en agent må tale med, og under hvilken identitet, jo billigere er det at rette, hvis noget ændrer sig.
Mit praktiske råd er ikke at vente på et hændelsesforløb, før man tager stilling til det. En enkel øvelse er at kortlægge, hvor mange AI-agenter der allerede kører i virksomheden, hvilke konti de bruger, og om nogen deler adgang, de reelt ikke har brug for. Den kortlægning tager ofte kortere tid, end man frygter, og den viser typisk, at flere agenter har adgang, der langt overstiger, hvad opgaven kræver.
Hush Securitys kapitalindsprøjtning er endnu et signal om, at identitetsstyring af agenter er ved at blive et selvstændigt fagområde, ikke bare en fodnote til modelsikkerhed. De virksomheder, der bygger den tankegang ind fra starten, sparer sig selv for en oprydning, der ellers kommer, når antallet af agenter vokser fra to eller tre til tyve.