Af Morten Overgaard Kristensen
Der findes allerede masser af skræmmende eksempler på AI-agenter, der løber løbsk.
En kodeassistent, der overskrev en start-ups kode, slettede hele produktionsdatabasen og forsøgte at dække over det ved at generere falske data og testresultater. To AI-agenter på en forskningsplatform, der kostede projektet næsten en kvart million fordi de kørte i ring og udvekslede beskeder med hinanden uafbrudt i 11 dage. Og mange flere, som vi nok aldrig hører om fordi de er for pinlige eller risikerer at underminere tilliden til AI-teknologierne i de pågældende virksomheder.
For AI-agenter er sjove at lege med. I produktion er de knap så sjove. Ikke fordi teknologien i sig selv er ondsindet, men fordi en agent, som bekendt, ikke kun svarer på vores spørgsmål, men også handler. Den kan læse, oprette, ændre, sende og slette data på tværs af systemer, hvis vi giver den lov.
Og i mit arbejde med AI, både M365 Copilot, agentisk automatisering i Copilot Studio og Foundry, og for den sags skyld digital workplace, ser jeg igen og igen, at virksomheder skalerer AI-værktøjer hurtigere, end de får styr på governance.
Hvis du, ligesom jeg, har vænnet dig til at alt bliver fortalt på syv sekunder og dit attention span er begyndt at sive, så får du den korte version først. Tre ting er afgørende fra start:
- Giv hver AI-agent sin egen unikke identitet
- Giv kun agenter de rettigheder, de absolut behøver
- Indbyg ejerskab, logning og lifecycle management i designet fra dag ét
Er du her endnu? Så lad os dykke ned i, hvorfor netop de tre principper er nøglen!
Uden ejerskab risikerer man, at agenten enten løber løbsk eller stille dør i glemsel. Modeller ændrer sig, systemer ændrer sig, data ændrer sig. En agent, der var genial i marts, kan blive en klods om benet i september, hvis ingen har vedligeholdt den.
Zero Trust starter med identitet
Hvis en agent kan agere på vegne af et menneske, skal vi kunne holde den ansvarlig. Derfor skal den aldrig gemme sig bag en generisk brugerkonto eller, værre endnu, køre under en rigtig bruger med brede rettigheder. Hver agent skal have sin egen tekniske identitet i virksomheden med et klart formål og en navngiven ejer. I Microsoft-verdenen er det her ikke længere noget man hacker sig til med servicekonti og service principals. Med Entra Agent ID får hver agent sin egen rigtige identitet, og det er præcis den udvikling der gør det muligt at gøre ordentligt.
Min erfaring er, at ejerskab er altafgørende. En AI-agent skal, ligesom en medarbejder, have en ansvarlig “leder”, der holder øje med den, opdaterer den og følger dens aktiviteter. Uden ejerskab risikerer man, at agenten enten løber løbsk eller stille dør i glemsel. Modeller ændrer sig, systemer ændrer sig, data ændrer sig. En agent, der var genial i marts, kan blive en klods om benet i september, hvis ingen har vedligeholdt den. Derfor: Giv agenten en ejer, der kan reagere, justere og tage ansvar.
Det interessante er, at Microsoft har taget præcis den her tankegang og gjort den til platform. Med Agent 365 og Entra Agent ID får hver agent ikke bare en identitet, men også en sponsor: en navngiven person der er ansvarlig for agentens adgang og livscyklus. Og forlader sponsoren virksomheden, overføres ansvaret automatisk til deres leder, så ingen agent ender herreløs.
Det er den samme pointe jeg har slået på i årevis, nu bare bygget ind i værktøjet.
Det er værd at bemærke, at det fulde setup kræver licens (Agent 365 per bruger, og P1/P2 for de skarpe sikkerhedspolitikker), og dele af det er stadig rimelig friskbagt fra ovnen. Men retningen er rigtig, og “fremtiden” er her allerede nu.
Kun snævre beføjelser til agenten
Så snart en agent får lov til at handle selv, ændrer behovet for styring sig markant. Jeg ser tit, at virksomheder starter med små personlige agenter (fx en chatrobot til individuel produktivitet) og derefter bevæger sig mod proces-agenter, der integrerer med CRM, ERP osv. Her skal man træde varsomt. Det handler om least privilege, så giv kun agenten de absolut nødvendige rettigheder.
Et par tommelfingerregler har hjulpet mig:
- Læseadgang er ikke det samme som skriveadgang.
- At oprette en sag er ikke det samme som at lukke den.
- At søge i dokumenter er ikke det samme som at dele dem eksternt.
Rettigheder bør designes som snævre capabilities med et klart formål. Hver ting, agenten må gøre, skal være veldefineret:
- Agenten må kalde dette specifikke API.
- Den må kun læse disse felter.
- Den må kun skrive til denne proces eller workflow.
- Og kun inden for den forretningskontekst, den er skabt til.
På den måde minimerer vi risikoen. Hvis (eller når) noget går galt, er skaden begrænset. Det gælder også just-in-time-adgange. Undgå permanente rettigheder, der bliver hængende og glemt. Giv hellere midlertidige adgange, som udløber automatisk, så agenten kun har rettigheder, når det er nødvendigt.
Ejerskab & logning
Governance handler ikke om at sige nej – det handler om at gøre et “ja” sikkert. Vi vil alle gerne kunne sige ja til at bruge AI-agenter, men under kontrollerede forhold. Derfor skal logning og kontrol tænkes ind fra dag ét. Alle agentens handlinger bør logges detaljeret, så man altid kan spore: Hvem (hvilken agent-identitet) gjorde hvad, hvornår og hvorfor.
Jeg anbefaler også på det kraftigste, at man ikke lader agenten tale direkte med de mest kritiske kernesystemer. Læg et kontrolleret lag imellem, fx en API-gateway, en orkestreringsserver eller en broker. Det mellemled kan:
- Validere agentens identitet og tilladelser ved hvert kald.
- Håndhæve politikker (f.eks. forhindre, at agenten sender visse data videre).
- Filtrere og maskere følsomme data, så agenten kun ser det, den må se.
- Logge alle handlinger centralt og ensartet.
Det er også her, vi begrænser såkaldt lateral movement. Hvis en agent skulle blive kompromitteret eller misbrugt, må den ikke kunne hoppe videre og udnytte andre systemer. Vi designer adgange og systemintegrationer, så skadespotentialet er så lille som muligt.
Jeg har set det i praksis. Gamle, rodede rettigheder giver ikke kun sikkerhedsrisici, de giver også elendige svar fra AI’en. Hvis brugere stadig har adgang til forældede projektrum, kan en agent som Microsoft 365 Copilot ende med at trække viden ind fra mapper, som ingen burde kigge i længere – med potentielt misvisende eller fortrolige informationer til følge. God governance i bunden er forudsætningen for gode AI-svar i toppen.
Pas på shadow AI og skjulte omkostninger
En sideeffekt af den aggressive AI-udvikling er det, der kaldes “shadow AI”, altså når medarbejdere tager AI-værktøjer i brug uden om de officielle kanaler.
Og jeg lover dig, at hvis jeres organisation ikke stiller klare og godkendte AI-værktøjer til rådighed, skal nogen nok finde en anden måde. Måske installerer en udvikler en lokal agent på sin bærbare for at hjælpe med en opgave, eller en projektleder fodrer en online chatbot med firmanoter. Uden retningslinjer sker det i skyggen og så har I nul kontrol over, hvilke data der ryger ud, og hvilke risici I løber.
Derfor bør minimale, men klare guidelines for AI-brug være på plads tidligt, herunder hvilke værktøjer må man bruge, og til hvad. Alt andet er et sikkerhedsgab.
Glem heller ikke omkostningerne i alt det her!
Cloud-forbrug kan vokse uden ejer, og AI-agenter kan gøre problemet endnu større. En autonom agent kan køre i baggrunden i timevis, forbruge tusindvis af tokens og kalde eksterne services uden at nogen lægger mærke til det før næste måneds regning. Det kan sammenlignes med “gammel” shadow IT.
Et klassisk eksempel er Microsoft 365, hvor gamle SharePoint-sites lever videre efter projektets slutning. Brugere har adgang til ting, de ikke længere skal bruge og en agent høster måske data derfra. Løsningen er ejerskab og oprydning. Altid have en ansvarlig for et givent system eller dataset, og sørge for at lukke ned for ting, der ikke længere skal være åbne.
Start småt men rigtigt
AI-agenter kan skabe enorm værdi, når de får adgang til de rigtige systemer under de rigtige forhold. Men giver I dem adgang uden klar identitet, uden ejerskab og uden sporbarhed, så skalerer I risikoen hurtigere end værdien. Min anbefaling er at begynde med én procesagent som pilotprojekt og så gøre alt efter bogen. Brug denne pilot til at få det fundamentale på plads:
- Kortlæg formål, data, systemer, handlinger og ejer. Find ud af præcis, hvad agenten skal (og ikke skal).
- Giv agenten sin egen identitet (med én ansvarlig ejer).
- Begræns dens capabilities strengt til det nødvendige.
- Log alt, hvad agenten foretager sig.
Når I har én agent kørende på den måde, vil I både se værdien og have ro i maven. Først derefter giver det mening at skalere op til flere agenter for så har I fundamentet og governance-modellen på plads.
