En policy, tusentals agenter: varför styrningen av AI i företag brister i stor skala

Mycket av diskussionen om införandet av autonoma AI-agenter har med rätta kretsat kring styrning som en avgörande utmaning. Gartner förutspådde nyligen att 40 % av företagen kommer att nedgradera eller avveckla sina autonoma AI-agenter senast 2027 – inte för att tekniken misslyckades, utan för att styrningen gjorde det. Enligt Gartner-analytikern Shiva Varma, senior director, är boven i dramat ”binär styrning”: att behandla agenter antingen som helt låsta eller som fullständigt betrodda, utan något däremellan.

Många organisationer tenderar just nu antingen att införa totalförbud mot AI-verktyg eller att använda agenter med otillräckliga skyddsåtgärder. Inget av tillvägagångssätten fungerar särskilt bra i stor skala. Även när IT-avdelningen förbjuder externa AI-verktyg förekommer skugg-AI ändå. Utvecklare vill naturligt nog bygga och lösa problem; om styrningen upplevs som alltför byråkratisk kommer de att kringgå kontrollerna och använda oprövade verktyg för att få arbetet gjort. Otillräckliga skyddsåtgärder utsätter däremot organisationer för säkerhetsmässiga, regelefterlevnadsrelaterade och operativa risker som ökar med tiden. 

Utmaningen är att AI-agenter inte kan styras enhetligt med en statisk lösning som ska passa alla.  Eran med styrning som ska passa alla går mot sitt slut, eftersom dessa system inte har samma riskprofil. De skiljer sig åt när det gäller den underliggande programvaran, funktionerna, åtkomstnivåerna och graden av autonomi. Att tillämpa statiska kontroller från industrisamhällets tid på programvara som arbetar i maskinhastighet kommer inte att fungera.  Effektiv styrning förutsätter att organisationer förstår programvaruförsörjningskedjan bakom varje agent och anpassar kontrollerna efter de risker som agenten medför.  

Styrning av agentbaserade programvaruutvecklingsmiljöer

Verklig kontroll innebär att effektivt hantera alla programvarukomponenter som ingår i agenten. Många team betraktar felaktigt dessa agenter som ”pålitliga och betrodda” och förbiser de standardkomponenter som påverkar deras funktion och säkerhet. 

Varje autonom AI-agent byggs upp av en välbekant uppsättning komponenter: en grundmodell, MCP-servrar (Model Context Protocol) som kopplar den till företagets data och externa system, insticksprogram som utökar dess funktioner samt färdighetsfiler som anger hur den ska bete sig. IT-chefer behöver ha följande i åtanke: 

• AI-agenter är programvaruekosystem: De bygger på en standarduppsättning som omfattar modeller, MCP:er, verktyg, insticksprogram, färdigheter och programvara med öppen källkod.
• MCP-servrar kan innebära risker: De kopplar agenter till företagets data och kan laddas ned precis som annan programvara. Om de inte granskas kan de ge hackare tillgång till ditt system. Till exempel lyfter ny forskning från JFrog Security Research fram just dessa risker i programvaruförsörjningskedjan i mcp-run-python, däribland en brist av typen Server-Side Request Forgery (SSRF) (CVE-2026-25904) och en sårbarhet till följd av bristande isolering (CVE-2026-25905) som kan leda till att MCP-miljön helt tas över.
• Insticksprogram kan öka riskerna: Olika agenter behöver olika insticksprogram (till exempel fungerar ett OpenAI-insticksprogram inte i Microsoft Copilot). Det innebär att företag ofta måste hantera flera varianter, och ett enda skadligt insticksprogram kan stjäla känslig information.
• Färdigheter styr agentens beteende: Dessa instruktionsfiler talar om för agenten hur den ska arbeta. Eftersom utvecklare hämtar dem från olika gemenskaper kan en manipulerad färdighet i det tysta förändra hur en agent fungerar.
• Risker med programvara med öppen källkod: Grunden för alla funktioner i lösningar som byggts med agentbaserad kodning är att binärfiler med öppen källkod används för att tillhandahålla funktionaliteten. Kodningsagenter kan lika gärna använda skadliga paket i stället för säkra utan att inse risken.
• Överblick är avgörande: Många team känner inte till att problemen finns, vilket gör deras agenter mycket sårbara. Organisationer hanterar fortfarande programvaruberoenden utifrån tillit i stället för genom noggranna kontroller.

System of record har en viktig roll i effektiv AI-styrning

Kapplöpningen om att införa AI-agenter i företag kan inte vinnas med gårdagens synsätt. Att införa centraliserade, tungrodda manuella godkännandekedjor i varje arbetsflöde hämmar innovationen, medan agenter som lämnas utan övervakning skapar onödiga risker.

För att kunna skala upp AI på ett säkert sätt måste organisationer införa ett skiktat tillvägagångssätt för styrning och säkring av programvarukomponenter, däribland paket, binärfiler, MCP:er, färdigheter och beroenden. Genom att skapa ett auktoritativt register kan företag välja ut alla komponenter som används, skanna allt innan användning, tillämpa policyer vid rätt tidpunkt i utvecklingslivscykeln och behålla möjligheten att omedelbart återställa ändringar. När nästa sårbarhet offentliggörs kan de alltså få svar på frågan ”är vi utsatta?” inom några minuter, inte dagar.

AI-agenter medför dock en bredare angreppsyta som förändras betydligt snabbare. Eftersom agenter med hög autonomi kan fatta hundratals beslut i minuten, kedja samman verktygsanrop, komma åt data och köra kod snabbare än traditionella kontroller vid införandet hinner med. Inledande granskningar och godkännandeprocesser spelar fortfarande en viktig roll, men räcker inte på egen hand för att säkra system som arbetar i maskinhastighet.

De här agenterna kräver dynamisk styrning under körning, med möjlighet att upptäcka avvikande beteende så snart det uppstår och ingripa innan skadan sprider sig. Tänk på det som en kretsbrytare: att återkalla åtkomsten till en komprometterad färdighet, koppla bort en datakontext som inte är betrodd eller blockera ett specifikt verktygsanrop så snart något går fel.

Bortom ”en lösning som passar alla”

En stel och enhetlig styrning är en säker väg till misslyckande. Tiden för att hinna före utvecklingen håller på att rinna ut, och styrningsskulden växer i takt med att införandet av agenter accelererar. Här är därför fyra steg som säkerhets- och teknikchefer kan ta nu för att stärka sina företagssystem:

1. Inventera vad som redan körs. De flesta företag kan inte hålla fullständig reda på vilka AI-agenter som finns i organisationen, än mindre på MCP-servrarna, insticksprogrammen och färdighetsfilerna som driver dem. Innan ni kan bedöma riskerna eller styra något måste ni veta vad som finns.
2. Behandla AI-komponenter som programvaruartefakter. MCP-servrar, färdighetsfiler och insticksprogram är inte konfiguration – de är kod och medför samma risker i leveranskedjan som beroenden med öppen källkod. Tillämpa samma granskning, skanning och ursprungsspårning som på alla bibliotek från tredje part.
3. Klassificera agenter efter autonominivå och anpassa kontrollerna därefter. Definiera vad ”hög autonomi” innebär för er organisation och bygg upp ett skiktat ramverk för policyer kring detta. Agenter med hög autonomi behöver kontroller under körning, inte bara kontroller vid införandet. Börja med era mest känsliga system och utöka sedan gradvis.
4. Gör styrningen tillräckligt snabb för att utvecklare – mänskliga eller agentbaserade – inte ska försöka kringgå den. Skugg-AI är ett friktionsproblem. Om det tar två veckor att godkänna en ny MCP-server kommer utvecklarna att hitta en annan väg. Automatiserad skanning med tydlig policytillämpning är den enda modellen som kan skalas i takt med den faktiska utvecklingstakten inom AI.

Styrningen blir betydligt effektivare när den tar hänsyn till de faktiska riskerna med varje agent i stället för att behandla alla likadant. De företag som kommer att gå före är de som anpassar styrningen efter varje agents förutsättningar, med stöd av ett registersystem som upprätthåller policyer vid varje gräns, ger insyn i varje komponent och gör det möjligt för team att agera så snart något går fel.