Styring av AI-agenter: Et rammeverk for bedriftsavdelinger

Innledning

TL;DR: Styring av AI-agenter er et sett med kontroller for identitet, retningslinjer, overvåking og revisjon som holder autonome agenter innenfor trygge grenser. Tradisjonell IT-styring ble utviklet for programvare som følger faste regler, og tar derfor ikke hensyn til måten agenter tar beslutninger, bruker verktøy og får tilgang til data på egen hånd. Denne veiledningen beskriver hva styring av agenter er, hvilke risikoer den håndterer, og et rammeverk du kan innføre før agenter integreres i kritiske arbeidsflyter.

En AI-agent kan lese en sak, foreta søk i tre interne systemer, utarbeide et svar og oppdatere en post uten at et menneske er involvert i noen av trinnene. Det er nettopp denne autonomien som er poenget. Det er også grunnen til at de fleste eksisterende styringskontrollene ikke passer. Tilgangsregler forutsetter at en person står bak hver handling, og revisjonslogger forutsetter at man kan spore handlingen tilbake til vedkommende. Agenter bryter begge disse forutsetningene.

Styring av AI-agenter lukker dette gapet. Den gir hver agent sin egen identitet, bestemmer hva hver enkelt har lov til å gjøre, overvåker hva den faktisk gjør og registrerer nok detaljer til å kunne svare på spørsmål senere. Vi går gjennom hvordan dette ser ut i praksis, de spesifikke risikoene det må dekke, og hvordan vi tilnærmer oss dette hos TrueFoundry.

Hva er styring av AI-agenter?

Styring av AI-agenter er fagområdet som handler om å kontrollere hvordan autonome agenter autentiserer seg, hvilke verktøy og data de har tilgang til, og hvordan handlingene deres overvåkes og loggføres. Det behandler en agent som en selvstendig aktør, ikke som en forlengelse av personen som satte den i drift.

Dette skillet er viktig fordi agenter tar uavhengige valg. En databaseagent kan ha lesetilgang, men det egentlige spørsmålet er om den bør foreta en søk i en tabell med kundedata for en gitt forespørsel. Styring er det som gir svar på dette spørsmålet i det øyeblikket forespørselen sendes, snarere enn under en gjennomgang flere uker senere. Uten dette ender teamene opp med å stole på at en agent vil holde seg innenfor rammene fordi ingenting har gått galt ennå.

God styring må også være praktisk. Hvis kontrollene gjør at agenter blir tregere eller vanskeligere å ta i bruk, vil teamene omgå dem, og da er man tilbake til ustyrte agenter med en styringspolicy som bare eksisterer på papiret.

Hvorfor tradisjonell tilgangskontroll ikke er tilstrekkelig for agenter

Standard tilgangskontroll tildeler tillatelser til brukere og loggfører handlinger knyttet til brukerkontoer. Agenter gjør denne modellen uklar på tre måter.

Ansvarliggjøringen blir uklar. Når en agent utfører en handling, viser loggen vanligvis en tjenestekonto, ikke personen som satte i gang forespørselen eller tankerekken som førte til handlingen. Hvis noe går galt, kan du se at en forespørsel ble kjørt, men ikke hvorfor eller på vegne av hvem.

Tilgangen til verktøy sprer seg. En enkelt agent kan nå dusinvis av verktøy og datakilder, hver med sin egen tillatelsesmodell. Dette omfanget vokser raskere enn noen manuell retningslinjeprosess kan følge med på, og det er i disse hullene hendelser oppstår.

Atferden endrer seg. Tradisjonell programvare gir samme utdata for samme inndata. Det gjør ikke agenter. Deres svar endres med samtalehistorikk, kontekst og endringer i den underliggende modellen, så en kontroll som var sikker forrige måned, kan oppføre seg annerledes i dag.

Ingen av disse er ekstreme tilfeller. De er de normale driftsforholdene for agenter, og det er derfor styringen må utformes spesielt for dem, i stedet for å lånes fra eldre systemer.

De fire pilarene i et rammeverk for styring av agenter

Et gjennomførbart rammeverk hviler på fire elementer som forsterker hverandre.

Identitet kommer først. Hver agent trenger sin egen identitet med avgrensede tillatelser, atskilt fra menneskene som bygger eller aktiverer den. Dette er det som gjør alt annet mulig, fordi du ikke kan håndheve eller kontrollere noe hvis du ikke kan skille agentene fra hverandre.

Håndheving av retningslinjer må skje under kjøring. Forskjellen mellom overvåking og styring er om systemet kan blokkere en uautorisert handling før den utføres, ikke bare markere den i etterkant. En skrivebeskyttet agent skal ikke kunne skrive, ikke bare bli rapportert for å ha forsøkt.

Observabilitet gir deg sanntidsinnsikt i hva agentene gjør. Du ønsker å se avvik, brudd på retningslinjer og risikable beslutninger når de skjer, slik at du reagerer på signaler i stedet for å rekonstruere hendelser fra ufullstendige logger.

Revisjonslogging fanger opp beslutningsforløpet. Hvert verktøyoppkall, hver datatilgang og hvert svar bør registreres med tilskrivning og kontekst, i en form du kan overlevere til en revisor eller en hendelsesbehandler. Dette er forskjellen mellom å si at en agent oppførte seg riktig og å kunne bevise det.

Risikoer knyttet til AI-agenter og hvordan du kan redusere dem

Agenter medfører risikoer som vanlig applikasjonssikkerhet ikke dekker fullt ut. Risikostyring for agentbasert AI begynner med å identifisere dem.

Promptinjeksjon er den største risikoen. Ondsinnet inndata skjult i brukerinnhold eller en ekstern datakilde kan få en agent til å lekke data eller utføre handlinger den aldri var ment å utføre. Agenter som behandler upålitelig innhold er mest utsatt.

Eksponering av påloggingsinformasjon kommer like etter. Agenter som har API-nøkler eller tokens, kan lekke disse i utdata eller logger, med mindre disse verdiene oppdages og maskeres underveis.

Lekkasje av personopplysninger skjer i det stille. Kundedata som strømmer gjennom en agent kan dukke opp i en samtalelogg, en feilmelding eller et nedstrømsanrop, uten at noen har bestemt at det skal skje.

Overdreven handlingsfrihet er risikoen ved å gi en agent mer enn den trenger. En kodeagent med skriveadgang til produksjonsrepositorier medfører en risiko som skrivebeskyttet tilgang ville eliminere fullstendig. Løsningen er å avgrense omfanget: gi hver agent det minimumet den trenger, og ikke mer.

Å redusere disse risikoene krever en kombinasjon av kontrolltiltak. Kontroller inn- og utdata for påloggingsopplysninger, PII og forbudt innhold før de krysser en grense. Lag en tillatelsesliste over de spesifikke verktøyene hver agent kan kalle opp, i stedet for å tillate alt som standard. Sett eskaleringsgrenser slik at beslutninger med høyere risiko blir videresendt til et menneske, og juster disse grensene ut fra hva du faktisk ser i produksjonsmiljøet.

Identitet per agent og påloggingsinformasjon med avgrenset tilgang

Delte tjenestekontoer er den vanligste snarveien, og de forårsaker mest problemer. Når flere agenter deler ett sett med påloggingsopplysninger, mister du muligheten til å vite hvilken agent som gjorde hva. Et sikkerhetsbrudd på den kontoen påvirker alle agenter som bruker den, ikke bare den som ble kompromittert. Og hver agent arver hele tillatelsessettet til den delte kontoen i stedet for et omfang som passer til oppgaven sin.

Identitet per agent løser alle tre problemene. Hver agent som tas i bruk, får sine egne påloggingsopplysninger som kan roteres og tilbakekalles hver for seg, tillatelser som gjenspeiler formålet og et oversiktlig revisjonsspor. Dette er også motgiften mot agentspredning – situasjonen der team setter opp agenter raskere enn noen klarer å holde oversikt over dem. Når hver agent har en registrert identitet, blir spredningen synlig i stedet for usynlig, og du kan håndtere den.

Identitetshåndtering for agenter krever andre abstraksjoner enn brukerhåndtering. Agenter trenger vedvarende identiteter som varer lenger enn en enkelt økt, påloggingsopplysninger som roteres uavhengig, og omfang knyttet til hva agenten gjør, snarere enn hvem som opprettet den.

Overholdelse av regelverk og revisjonsklarhet

Reguleringene er i ferd med å innhente autonome systemer, og rammeverk som SOC 2, HIPAA og GDPR skaper allerede forpliktelser som agentdistribusjoner må oppfylle. Det praktiske kravet er en infrastruktur som selv genererer bevis, i stedet for dokumentasjon som noen setter sammen manuelt før en revisjon.

Det betyr omfattende revisjonsspor, der hver eneste agenthandling loggføres sammen med tilskrivning, tidsstempel og kontekst. Det betyr uforanderlige oppføringer som ikke kan redigeres i etterkant. Det betyr oppbevaring som samsvarer med reglene for dine oppføringstyper og jurisdiksjoner, samt muligheten til å eksportere logger til sikkerhetsverktøyene teamet ditt allerede bruker.

For regulerte team er det like viktig hvor agentene kjører som hvordan de styres. Å kjøre agenter i din egen VPC, lokalt eller i et air-gapped miljø holder sensitive data innenfor dine grenser, samtidig som de samme identitets-, policy- og loggkontrollene gjelder.

Hvordan TrueFoundry tilnærmer seg styring av agenter

Vi har bygget plattformen vår slik at styring er en integrert del av hvordan agenter kjører, ikke et lag som er lagt til i etterkant. Agent Gateway gir hver agent sin egen identitet med begrensede, roterbare påloggingsopplysninger, slik at handlinger kan tilskrives den rette personen og at tillatelser samsvarer med agentens oppgave, snarere enn tilgangen til den som opprettet den.

Tilgang til verktøy skjer gjennom det samme kontrollplanet. Agenter får tilgang til verktøy og data via MCP med OAuth2, RBAC og metadatapolitikker som gjelder for hvert verktøyoppkall, noe som lar deg tillate lesing av en database samtidig som du blokkerer skriving. Sikkerhetsbarrierer inspiserer forespørsler og svar for personopplysninger og annet forbudt innhold både på inngangs- og utgangsveiene, og hvert anrop loggføres for overvåking og revisjon. Fordi plattformen kjører i din VPC, lokalt eller i et air-gapped miljø med støtte for SOC 2, HIPAA og GDPR, gjelder styringskontrollene uansett hvor agentene dine kjører.

Resultatet er at identitet, retningslinjer for kjøretid, overvåking og revisjon kommer fra ett sted i stedet for fire uavhengige verktøy, og det er dette som gjør at rammeverket henger sammen i stor skala.

Å bygge praksisen rundt teknologien

Kontrolltiltak fungerer bare når organisasjonen støtter dem. Team som ser på styring som en hindring, vil finne måter å omgå den på, så målet er å gjøre den styrte veien til den enkleste veien.

En trinnvis utrulling pleier å fungere: finn agentene som allerede kjører, gi dem identiteter, slå på overvåking, og automatiser deretter dokumentasjonen av samsvar. Tidspunktet avhenger av hvor komplekst miljøet ditt er og hvilke regelverk som gjelder. I tillegg bør en tverrfunksjonell gruppe som dekker plattformutvikling, juridiske forhold, samsvar og drift, ta ansvar for retningslinjebeslutninger og håndtere nye tilfeller som eksisterende retningslinjer ikke dekker. Opplæring fullfører bildet, slik at de som utvikler agenter forstår tillatelsesmodellen og vet hvordan de skal anvende sikkerhetsbarrierer på sine egne bruksscenarier.

Ofte stilte spørsmål

Hva er styring av AI-agenter?

Styring av AI-agenter er et sett med kontroller som regulerer hvordan autonome agenter autentiserer seg, hvilke verktøy og data de har tilgang til, og hvordan handlingene deres overvåkes og revideres. Det behandler hver agent som en egen aktør med avgrensede tillatelser, i stedet for å la agenter arve tilgangen til den som har distribuert dem.

Hvordan skiller risikostyring for agentbasert AI seg fra vanlig applikasjonssikkerhet?

Det medfører risikoer som standard sikkerhet ikke fullt ut tar høyde for, inkludert prompt-injeksjon, lekkasje av påloggingsinformasjon gjennom agentutdata, eksponering av personopplysninger i samtalelogger og overdreven handlefrihet som følge av for vidtrekkende tillatelser. For å håndtere dette kreves inspeksjon av inngangs- og utdata under kjøring, tillatelseslister på verktøynivå og avgrensning av minste mulig privilegium per agent.

Hvorfor er identitet per agent viktig?

Delte tjenestekontoer gjør det umulig å vite hvilken agent som utførte en handling, utvider skadeomfanget dersom påloggingsopplysninger kompromitteres, og gir hver agent mer tilgang enn den trenger. Identitet per agent gir hver agent egne, roterbare påloggingsopplysninger, entydig tilskrivning og et omfang som samsvarer med formålet.

Kan jeg kjøre agentstyring i min egen VPC eller lokalt?

Ja. TrueFoundry kjører i din VPC, lokalt, i et air-gapped miljø eller på tvers av skytjenester, slik at ingen data forlater domenet ditt. De samme identitets-, policy- og revisjonskontrollene gjelder uansett hvor agentene kjører, og det er grunnen til at regulerte team velger en selvhostet modell fremfor en ren SaaS-gateway.

Støtter dette SOC 2, HIPAA og GDPR?

TrueFoundry støtter SOC 2-, HIPAA- og GDPR-standardene, med innebygd RBAC, SSO og uforanderlig revisjonsloggføring. Denne kombinasjonen gjør agentdistribusjonene klare for revisjon, i stedet for at du må stresse med å dokumentere alt i siste liten før en gjennomgang.

Konklusjon

Styring av AI-agenter er det som skiller agenter du kan skalere, fra agenter du må krysse fingrene for. Rammeverket er i prinsippet ikke komplisert: Gi hver agent en identitet, håndhev retningslinjer i det øyeblikket handlingen utføres, overvåk hva agentene gjør, og før en logg du kan stå inne for. Det som gjør det vanskelig, er å gjøre alle fire tingene samtidig, for alle agenter, uten å bremse teamene. Det er dette laget vi har satt oss som mål å tilby. Se hvordan TrueFoundrys AI Gateway samler identitet, retningslinjer og overvåking i ett styrt kontrollplan for agentene dine.