Styring af AI-agenter: En ramme for virksomhedsteams

Introduktion

TL;DR: AI-agentstyring er den samlede række af identitets-, politik-, overvågnings- og revisionskontroller, der holder autonome agenter inden for sikre grænser. Traditionel IT-styring blev udviklet til software, der følger faste regler, og tager derfor ikke højde for den måde, agenter træffer beslutninger, aktiverer værktøjer og får adgang til data på egen hånd. Denne vejledning beskriver, hvad agentstyring er, hvilke risici den adresserer, samt en ramme, du kan implementere, inden agenterne integreres i kritiske arbejdsgange.

En AI-agent kan læse en ticket, forespørge tre interne systemer, udarbejde et svar og opdatere en post, uden at et menneske rører ved et eneste trin. Den autonomi er netop pointen. Det er også grunden til, at de fleste eksisterende styringsmekanismer ikke passer. Adgangsregler forudsætter, at der står en person bag hver handling, og revisionslogfiler forudsætter, at man kan spore handlingen tilbage til den pågældende person. Agenter bryder begge disse antagelser.

Governance af AI-agenter lukker dette hul. Den giver hver agent sin egen identitet, bestemmer, hvad den enkelte må gøre, overvåger, hvad den rent faktisk gør, og registrerer tilstrækkelige detaljer til at besvare spørgsmål senere. Vi gennemgår, hvordan det ser ud i praksis, hvilke specifikke risici det skal dække, og hvordan vi griber det an hos TrueFoundry.

Hvad er AI-agentstyring?

AI-agentstyring er disciplinen, der handler om at kontrollere, hvordan autonome agenter autentificerer sig, hvilke værktøjer og data de har adgang til, og hvordan deres handlinger overvåges og registreres. Den behandler en agent som en selvstændig enhed i sig selv, ikke som en forlængelse af den person, der har implementeret den.

Denne skelnen er vigtig, fordi agenter træffer uafhængige valg. En databaseagent kan have læseadgang, men det egentlige spørgsmål er, om den bør forespørge en tabel med kundedata i forbindelse med en given anmodning. Styring er det, der besvarer dette spørgsmål i det øjeblik, anmodningen fremsættes, snarere end under en gennemgang uger senere. Uden styring ender teams med at stole på, at en agent vil holde sig inden for rammerne, fordi der endnu ikke er gået noget galt.

God styring skal også være praktisk. Hvis kontrollerne gør agenterne langsomme eller svære at implementere, vil teams omgå dem, og så er man tilbage ved ustyrede agenter med en styringspolitik, der kun eksisterer på papiret.

Hvorfor traditionel adgangskontrol ikke er tilstrækkelig for agenter

Standardadgangskontrol tildeler tilladelser til brugere og logger handlinger på brugerkonti. Agenter udvisker denne model på tre måder.

Tildelingen bliver uklar. Når en agent handler, viser loggen normalt en servicekonto, ikke den person, der satte anmodningen i gang, eller den tankegang, der førte til handlingen. Hvis noget går galt, kan man se, at der blev kørt en forespørgsel, men ikke hvorfor eller på vegne af hvem.

Adgangen til værktøjer breder sig. En enkelt agent kan nå ud til snesevis af værktøjer og datakilder, der hver har sin egen tilladelsesmodel. Dette område vokser hurtigere, end nogen manuel politikproces kan følge med, og det er i disse huller, at hændelserne opstår.

Adfærden ændrer sig. Traditionel software returnerer det samme output for den samme input. Det gør agenter ikke. Deres svar ændrer sig i takt med samtalehistorikken, konteksten og ændringer i den underliggende model, så en kontrol, der var sikker i sidste måned, kan opføre sig anderledes i dag.

Ingen af disse er sjældne tilfælde. Det er de normale driftsbetingelser for agenter, og derfor skal styringen udformes med henblik på dem i stedet for at blive lånt fra ældre systemer.

De fire søjler i en ramme for agentstyring

En brugbar ramme hviler på fire elementer, der styrker hinanden.

Identitet kommer først. Hver agent har brug for sin egen identitet med afgrænsede tilladelser, adskilt fra de mennesker, der bygger eller aktiverer den. Det er det, der gør alt andet muligt, for man kan ikke håndhæve eller kontrollere noget, hvis man ikke kan skelne mellem agenterne.

Håndhævelse af politikker skal ske under kørsel. Forskellen mellem overvågning og styring er, om systemet kan blokere en uautoriseret handling, før den udføres, og ikke blot markere den bagefter. En skrivebeskyttet agent bør være ude af stand til at skrive, ikke blot blive rapporteret for at have forsøgt.

Observabilitet giver dig realtidsindsigt i, hvad agenterne foretager sig. Du vil gerne se afvigelser, politikbrud og risikable beslutninger, når de sker, så du reagerer på signaler i stedet for at rekonstruere hændelser ud fra ufuldstændige logfiler.

Revisionslogning registrerer beslutningsforløbet. Hvert værktøjsopkald, hver dataadgang og hvert svar bør registreres med tilskrivning og kontekst i en form, du kan videregive til en revisor eller en hændelsesbehandler. Det er forskellen mellem at sige, at en agent opførte sig korrekt, og at kunne bevise det.

Risici ved AI-agenter og hvordan man reducerer dem

Agenter medfører risici, som almindelig applikationssikkerhed ikke fuldt ud dækker. Risikostyring af agentbaseret AI starter med at navngive dem.

Prompt-injektion er den største risiko. Ondsindet input skjult i brugerindhold eller en ekstern datakilde kan få en agent til at lække data eller udføre handlinger, den aldrig var beregnet til at udføre. Agenter, der behandler upålideligt indhold, er mest udsatte.

Eksponering af legitimationsoplysninger ligger tæt efter. Agenter, der opbevarer API-nøgler eller -tokens, kan lække dem i output eller logfiler, medmindre disse værdier opdages og maskeres undervejs.

Lækage af personoplysninger sker ubemærket. Kundedata, der strømmer gennem en agent, kan dukke op i en samtalelog, en fejlmeddelelse eller et efterfølgende opkald, uden at nogen har besluttet, at det skal ske.

Overdreven handlefrihed er risikoen ved at give en agent mere, end den har brug for. En kodeagent med skriveadgang til produktionsrepositorier udgør en risiko, som skrivebeskyttet adgang ville fjerne fuldstændigt. Løsningen er afgrænsning: Giv hver agent det minimum, den har brug for, og ikke mere.

At reducere disse risici kræver en kombination af kontrolforanstaltninger. Undersøg ind- og uddata for legitimationsoplysninger, personoplysninger og forbudt indhold, før de krydser en grænse. Lav en tilladelsesliste over de specifikke værktøjer, som hver agent må kalde, i stedet for at tillade alt som standard. Indstil eskaleringstærskler, så beslutninger med højere risiko videresendes til et menneske, og finjuster disse tærskler ud fra det, du rent faktisk ser i produktionen.

Identitet pr. agent og adgangsoplysninger med afgrænset rækkevidde

Delte servicekonti er den mest almindelige genvej, og de skaber flest problemer. Når flere agenter deler ét sæt legitimationsoplysninger, mister man muligheden for at se, hvilken agent der har gjort hvad. Et sikkerhedsbrud på den pågældende konto påvirker alle agenter, der bruger den, ikke kun den, der blev kompromitteret. Og hver agent arver det fulde sæt tilladelser fra den delte konto i stedet for et omfang, der passer til dens opgave.

Agentbaseret identitet løser alle tre problemer. Hver implementeret agent får sine egne legitimationsoplysninger, der kan roteres og tilbagekaldes uafhængigt, tilladelser, der afspejler dens formål, og et klart revisionsspor. Dette er også modgiften mod agent-spredning – den situation, hvor teams opretter agenter hurtigere, end nogen kan holde styr på dem. Når hver agent har en registreret identitet, bliver spredningen synlig i stedet for usynlig, og man kan styre den.

Identitetsstyring for agenter kræver andre abstraktioner end brugerstyring. Agenter har brug for permanente identiteter, der varer længere end en enkelt session, adgangsoplysninger, der skiftes uafhængigt, og omfang, der er knyttet til, hvad agenten gør, snarere end hvem der har oprettet den.

Overholdelse af regler og revisionsparathed

Reguleringen er ved at indhente de autonome systemer, og rammeværker som SOC 2, HIPAA og GDPR skaber allerede forpligtelser, som agentimplementeringer skal opfylde. Det praktiske krav er en infrastruktur, der selv genererer beviser, frem for dokumentation, som nogen samler manuelt inden en revision.

Det betyder omfattende revisionsspor, hvor hver eneste agenthandling logges sammen med tilskrivning, tidsstempel og kontekst. Det betyder uforanderlige optegnelser, der ikke kan redigeres efterfølgende. Det betyder opbevaring, der overholder reglerne for dine optegnelsestyper og jurisdiktioner, samt muligheden for at eksportere logfiler til de sikkerhedsværktøjer, dit team allerede bruger.

For regulerede teams er det lige så vigtigt, hvor agenterne kører, som hvordan de styres. At køre agenter inden for din egen VPC, on-prem eller i et air-gapped miljø holder følsomme data inden for dine grænser, samtidig med at de samme identitets-, politik- og logningskontroller gælder.

Sådan tilgår TrueFoundry styring af agenter

Vi har bygget vores platform, så styring er en integreret del af, hvordan agenterne kører, og ikke et lag, der er boltet på senere. Agent Gateway giver hver agent sin egen identitet med afgrænsede, roterbare legitimationsoplysninger, så handlinger kan tilskrives, og tilladelser matcher agentens opgave frem for dens opretters adgang.

Adgangen til værktøjer foregår via det samme kontrolplan. Agenterne får adgang til værktøjer og data via MCP med OAuth2, RBAC og metadatapolitikker, der anvendes på hvert værktøjsopkald, hvilket giver dig mulighed for at tillade læsning af en database, mens skrivning blokeres. Guardrails inspicerer anmodninger og svar for personoplysninger (PII) og andet forbudt indhold på både indgangs- og udgangsstierne, og hvert opkald logges med henblik på overvågning og revision. Da platformen kører i din VPC, on-prem eller i et air-gapped miljø med understøttelse af SOC 2, HIPAA og GDPR, gælder styringskontrollerne uanset hvor dine agenter kører.

Resultatet er, at identitet, runtime-politik, overvågning og revision kommer fra ét sted i stedet for fire uafhængige værktøjer, hvilket er det, der får rammen til at hænge sammen i stor skala.

Opbygning af praksis omkring teknologien

Kontroller fungerer kun, når organisationen bakker op om dem. Teams, der betragter styring som en hindring, vil finde måder at omgå den på, så målet er at gøre den styrede vej til den nemme vej.

En trinvis implementering fungerer som regel godt: Find de agenter, der allerede kører, tildel dem identiteter, aktiver overvågningen og automatiser derefter dokumentationen for overholdelse. Tidspunktet afhænger af, hvor komplekst dit miljø er, og hvilke regler der gælder. Derudover bør en tværfunktionel gruppe, der dækker platformudvikling, juridiske forhold, compliance og drift, stå for beslutninger om politikker og håndtere de nye tilfælde, som de eksisterende politikker ikke dækker. Uddannelse fuldender det hele, så de personer, der udvikler agenter, forstår tilladelsesmodellen og ved, hvordan de skal anvende sikkerhedsforanstaltninger i deres egne anvendelsesscenarier.

Ofte stillede spørgsmål

Hvad er AI-agentstyring?

AI-agentstyring er det sæt af kontrolmekanismer, der styrer, hvordan autonome agenter autentificerer sig, hvilke værktøjer og data de har adgang til, og hvordan deres handlinger overvåges og revideres. Det behandler hver agent som sin egen hovedperson med afgrænsede tilladelser, i stedet for at lade agenterne arve adgangen fra den person, der har implementeret dem.

Hvordan adskiller risikostyring af agentbaseret AI sig fra almindelig applikationssikkerhed?

Den medfører risici, som standard sikkerhed ikke fuldt ud imødegår, herunder prompt-injektion, lækage af legitimationsoplysninger via agenters output, eksponering af personlige oplysninger i samtalelogfiler og overdreven handlefrihed som følge af for brede tilladelser. Håndtering af disse risici kræver inspektion af input og output under kørsel, tilladelseslister på værktøjsniveau og afgrænsning af mindst mulig adgang pr. agent.

Hvorfor er identitet pr. agent vigtig?

Delte servicekonti gør det umuligt at se, hvilken agent der har udført en handling, øger omfanget af skaden, hvis legitimationsoplysninger kompromitteres, og giver hver agent mere adgang, end den har brug for. Identitet pr. agent giver hver agent sine egne legitimationsoplysninger, der kan skiftes, entydig tilskrivning og et omfang, der matcher dens formål.

Kan jeg køre agentstyring i min egen VPC eller on-prem?

Ja. TrueFoundry kører i din VPC, on-prem, i et air-gapped miljø eller på tværs af skyer, så ingen data forlader dit domæne. De samme identitets-, politik- og revisionskontroller gælder, uanset hvor agenterne kører, hvilket er grunden til, at regulerede teams vælger en selvhostet model frem for en ren SaaS-gateway.

Understøtter dette SOC 2, HIPAA og GDPR?

TrueFoundry understøtter SOC 2-, HIPAA- og GDPR-standarder med indbygget RBAC, SSO og uforanderlig revisionslogning. Det er netop denne kombination, der gør agentinstallationer revisionsklare i stedet for noget, du skal skynde dig at dokumentere inden en gennemgang.

Konklusion

Styring af AI-agenter er det, der adskiller agenter, man kan skalere, fra agenter, man blot kan håbe på. Rammeværket er i princippet ikke kompliceret: Giv hver agent en identitet, håndhæv politikken i det øjeblik, der handles, overvåg, hvad agenterne gør, og før en log, man kan stå inde for. Det, der gør det svært, er at udføre alle fire ting på én gang for alle agenter uden at bremse teamene. Det er netop det lag, vi har sat os for at levere. Se, hvordan TrueFoundrys AI Gateway samler identitet, politikker og overvågning i ét reguleret kontrolplan for dine agenter.