Tankeledere

Én policy, tusenvis av agenter: Hvorfor styring av KI i virksomheter svikter når omfanget øker

mm
Legg til Unite.AI blant dine foretrukne kilder på Google

Mye av samtalen om innføringen av autonome KI-agenter har dreid seg om styring som en sentral utfordring, og med god grunn. Gartner spådde nylig at 40 % av virksomhetene vil nedgradere eller avvikle sine autonome KI-agenter innen 2027 – ikke fordi teknologien sviktet, men fordi styringen deres gjorde det. Ifølge Gartner-analytikeren Shiva Varma, som er seniordirektør, er synderen «binær styring»: at agenter enten behandles som fullstendig låst ned eller som fullt ut betrodde, uten noen mellomting.

Akkurat nå tyr mange organisasjoner enten til totalforbud mot KI-verktøy eller tar i bruk agenter med utilstrekkelige sikkerhetstiltak. Ingen av tilnærmingene skalerer godt. Selv når IT-avdelingen forbyr eksterne KI-verktøy, forekommer skygge-KI likevel. Utviklere ønsker naturlig nok å bygge og løse problemer; hvis styringen oppleves som altfor byråkratisk, vil de omgå kontrollene og bruke uprøvde verktøy for å holde arbeidet i gang. Utilstrekkelige sikkerhetstiltak utsetter derimot organisasjoner for sikkerhetsmessige, regulatoriske og driftsmessige risikoer som øker over tid. 

Utfordringen er at KI-agenter ikke kan styres på en ensartet måte med en statisk tilnærming som skal passe alle.  Tiden for en slik styring er forbi, fordi disse systemene ikke har samme risikoprofil: De er forskjellige når det gjelder den underliggende programvaren, funksjonaliteten, tilgangsnivåene og graden av autonomi. Det vil ikke fungere å bruke statiske kontrollmekanismer fra industriepoken på programvare som opererer i maskinhastighet.  Effektiv styring vil avhenge av at organisasjoner forstår programvareforsyningskjeden bak hver agent og tilpasser kontrollene til risikoene den introduserer.  

Styring av agentbaserte programvareutviklingsmiljøer

Reell kontroll innebærer å håndtere alle programelementene som inngår i agenten, på en effektiv måte. Mange team anser feilaktig disse agentene som «pålitelige og betrodde» og overser de vanlige elementene som påvirker funksjonaliteten og sikkerheten deres. 

Alle autonome KI-agenter er bygget opp av en gjenkjennelig stabel: en grunnmodell, MCP-servere (Model Context Protocol) som kobler agenten til virksomhetens data og eksterne systemer, programtillegg som utvider funksjonaliteten, og ferdighetsfiler som beskriver hvordan den skal oppføre seg. IT-ledere bør ha følgende i mente: 

  • KI-agenter er programvareøkosystemer: De bygger på et standardoppsett med modeller, MCP-er, verktøy, programtillegg, ferdigheter og programvare med åpen kildekode.
  • MCP-servere kan innebære risiko: De kobler agenter til virksomhetens data og kan lastes ned som all annen programvare. Hvis de ikke kontrolleres, kan de gi hackere tilgang til systemet ditt. For eksempel viser nyere sikkerhetsundersøkelser fra JFrog at disse risikoene i programvareforsyningskjeden finnes i mcp-run-python, blant annet en sårbarhet for forfalskning av forespørsler på serversiden (SSRF) (CVE-2026-25904) og en sårbarhet som skyldes manglende isolasjon (CVE-2026-25905) som kan føre til fullstendig overtakelse av MCP.
  • Programtillegg kan øke risikoen: Ulike agenter trenger ulike programtillegg (for eksempel fungerer ikke et programtillegg for OpenAI i Microsoft Copilot). Det betyr at selskaper ofte må håndtere flere varianter, og at ett enkelt skadelig programtillegg kan stjele sensitiv informasjon.
  • Ferdigheter definerer agentens atferd: Disse instruksjonsfilene forteller agenten hvordan den skal arbeide. Fordi utviklere henter dem fra fellesskapskilder, kan en manipulert ferdighet i det stille endre hvordan en agent fungerer.
  • Risikoer ved programvare med åpen kildekode: Funksjonaliteten i løsninger utviklet med agentbasert koding bygger på bruk av binærfiler med åpen kildekode. Kodeagenter kan like gjerne bruke skadelige pakker i stedet for trygge, uten å være klar over risikoen.
  • Innsyn er avgjørende: Mange team vet ikke at disse problemene finnes, noe som gjør agentene deres svært sårbare. Organisasjoner håndterer fortsatt programvareavhengigheter basert på tillit i stedet for grundige kontroller.

Rollen til et autoritativt register i effektiv KI-styring

Kampen om å ta i bruk KI-agenter i virksomheter kan ikke vinnes med gårsdagens tankegang. Omfattende, tungrodde manuelle godkjenningsprosesser for hver arbeidsflyt hemmer innovasjon, mens agenter som ikke overvåkes, skaper unødvendig risiko.

For å kunne skalere KI på en trygg måte må organisasjoner innføre en lagdelt tilnærming til styring og sikring av programvarekomponenter, blant annet pakker, binærfiler, MCP-er, ferdigheter og avhengigheter. Ved å etablere et autoritativt register kan virksomheter holde oversikt over alle komponentene som brukes, skanne alt før bruk, håndheve retningslinjer på riktig tidspunkt i utviklingsløpet, og sørge for at det er mulig å rulle tilbake endringer umiddelbart. Når den neste sårbarheten blir offentliggjort, kan de dermed få svar på spørsmålet «er vi berørt?» i løpet av minutter, ikke dager.

AI-agenter utvider imidlertid angrepsflaten og gjør den betydelig mer dynamisk. Agenter med høy grad av autonomi kan ta hundrevis av beslutninger i minuttet, kjede sammen verktøykall, få tilgang til data og kjøre kode raskere enn tradisjonelle inntakskontroller kan holde tritt. Innledende gjennomganger og godkjenningsprosesser spiller fortsatt en viktig rolle, men de kan ikke alene sikre systemer som opererer i maskinhastighet.

Disse agentene krever dynamisk håndheving under kjøring, med mulighet til å oppdage unormal atferd idet den oppstår og gripe inn før skaden sprer seg. Tenk på det som en automatsikring: å tilbakekalle tilgangen til en kompromittert ferdighet, koble fra en datakontekst man ikke har tillit til, eller blokkere et bestemt verktøykall idet noe går galt.

På vei bort fra «én løsning som passer alle»

En rigid og ensartet styringsmodell er en sikker oppskrift på fiasko. Muligheten til å komme dette i forkjøpet er i ferd med å glippe, og styringsgjelden vokser etter hvert som utrullingen av agenter skyter fart. Her er derfor fire tiltak sikkerhets- og teknologiledere kan iverksette nå for å styrke virksomhetens systemer:

  1. Få oversikt over hva som allerede kjører. De fleste virksomheter har ikke full oversikt over AI-agentene de bruker, langt mindre MCP-serverne, programtilleggene og ferdighetsfilene som driver dem. Før du kan vurdere risikoen eller styre noe som helst, må du vite hva som finnes.
  2. Behandle AI-komponenter som programvareartefakter. MCP-servere, ferdighetsfiler og programtillegg er ikke konfigurasjon – de er kode med de samme risikoene i forsyningskjeden som enhver annen åpen kildekode-avhengighet. Bruk den samme kontrollen, skanningen og sporingen av opprinnelse som du ville brukt på et hvilket som helst tredjepartsbibliotek.
  3. Klassifiser agenter etter graden av autonomi, og tilpass kontrollene deretter. Definer hva «høy autonomi» betyr for virksomheten din, og bygg et lagdelt rammeverk for retningslinjer rundt dette. Agenter med høy grad av autonomi trenger håndheving under kjøring, ikke bare kontroller ved innføring. Begynn med de mest sensitive systemene, og utvid derfra.
  4. Sørg for at styringen går raskt nok til at utviklere, enten de er mennesker eller agenter, ikke finner omveier rundt den. Skygge-AI skyldes friksjon. Hvis det tar to uker å godkjenne en ny MCP-server, finner utviklerne en annen måte. Automatisert skanning med tydelig håndheving av retningslinjer er den eneste modellen som kan holde tritt med den faktiske utviklingstakten innen AI.

Styringen blir langt mer effektiv når den tar hensyn til den faktiske risikoen hver agent utgjør, i stedet for å behandle alle likt. Virksomhetene som vil ligge i forkant, er de som tilpasser styringen til realitetene for hver enkelt agent, med støtte fra et autoritativt register som håndhever retningslinjene ved hver grense, gir oversikt over hver komponent og gjør det mulig for teamene å reagere idet noe går galt.

Paul er en erfaren IT-sikkerhetssjef som, som Field CISO i JFrog, jobber for å hjelpe CISOer, IT-ledere og sikkerhetsteam med å styrke beskyttelsen av deres programvareforsyningskjede. I tillegg gir han råd til IT-sikkerhetsoppstartsbedrifter, veileder sikkerhetsledere og gir veiledning om ulike IT-sikkerhetstrender. Paul bruker også tiden sin på å utforske den nyeste teknologien, være DJ, lese og kjøre båt.