Microsoft gjør agentstyring til policy før verktøykall

Microsofts Agent Governance Toolkit gjør et enkelt poeng svært tydelig: AI-agenter kan ikke styres med høflige instruksjoner alene. Når agenter får tilgang til e-post, databaser, kodebaser, nettleser, MCP-servere og andre agenter, må hvert verktøykall gjennom en egen kontrollflate før det når produksjonssystemet.

Prosjektet ligger i Microsofts GitHub-organisasjon og er merket som public preview. Det beskrives som et verktøysett for policy enforcement, identitet, sandboxing og SRE for autonome AI-agenter. Det er ikke en ny modell. Det er limet rundt modellen. Akkurat der mange norske virksomheter fortsatt har et hull.

Kjernen er at agentens handlinger skal fanges opp i deterministisk applikasjonskode. Microsoft skriver at «prompt-level safety» ikke er en kontrollflate, men en høflig forespørsel til et stokastisk system. Derfor skal verktøykall, meldinger og delegeringer avskjæres før modellens intensjon når nettverket. Hvis policy-motoren sier nei, skal handlingen ikke bli mindre sannsynlig. Den skal bli strukturelt umulig.

Det er et voksent skifte i agentdebatten. I 2024 og 2025 handlet mye om om modellen kunne utføre oppgaven. I 2026 handler mer om hvem som kan bevise hva agenten gjorde, hvem den handlet på vegne av, og om virksomheten kan stoppe den før den gjør noe dyrt. Det er forskjellen på en demo og et system en CISO kan la komme nær reelle data.

Microsofts eksempel er lett å forstå. En agent med tilgang til send_email og query_database bør ikke kunne kjøre drop_table. OAuth-scopes og IAM-roller sier noe om hvilke tjenester agenten når. De sier lite om hva agenten gjør etter at den er koblet til. Agent Governance Toolkit legger derfor en policy-motor mellom agenten og verktøyet. Policy kan uttrykkes i blant annet YAML, OPA eller Cedar. Hver beslutning kan logges, godkjennes, nektes eller sendes til menneskelig godkjenning.

Verktøysettet dekker mer enn enkel allow/deny-logikk. README-en peker på Agent OS for policy og livssyklus, Agent Mesh for identitet og tillit mellom agenter, Agent Runtime for execution sandboxing, Agent SRE for kill switch, SLO-overvåking og chaos testing, og Agent Compliance for OWASP-sjekker, policy-linting og integritetskontroller. Det finnes også en MCP Security Gateway for tool poisoning, drift detection, typosquatting og skjulte instruksjoner.

Det siste er viktig. MCP har raskt blitt en standard måte å koble agenter til interne systemer og eksterne verktøy på. Samtidig øker risikoen for at et verktøy, en skill eller en server tar med seg skjulte instruksjoner inn i agentens kontekst. Når agenten både leser og handler, er prompt injection ikke bare et tekstproblem. Det er en tilgangsstyringsfeil med språkmodell på toppen.

Microsoft forsøker også å gjøre dette rammeverksuavhengig. Prosjektet viser støtte eller adaptere for Microsoft Agent Framework, Semantic Kernel, AutoGen, LangGraph, CrewAI, OpenAI Agents SDK, Claude Code, Google ADK, LlamaIndex, Haystack, Mastra, Dify, Azure AI Foundry og GitHub Copilot CLI. Det er et signal om hvor markedet er på vei. Agentstyring kan ikke låses til én modell eller én leverandør hvis virksomheter skal bruke flere agenter på tvers av sky, kode og fagsystemer.

For ledere er dette særlig relevant fordi agentbruk ofte vokser nedenfra. Utviklere prøver Claude Code, Copilot CLI, Codex, Cursor, LangGraph eller interne MCP-koblinger før governance-modellen er ferdig. Resultatet blir fort en skyggeflåte av agenter med ulik logging, ulike tokens og uklare eiere. Microsoft kaller en av funksjonene Shadow AI Discovery. Bare navnet treffer en nerve.

Verktøysettet lover ikke magi. Microsoft er tydelig på at governance håndheves i applikasjonslaget, ikke som en OS-kjerne. Prosjektet anbefaler separate containere for agenter som trenger sterkere isolasjon. Det er en nyttig begrensning å ha med i innkjøpsdialogen. Dette er kontrollflate, ikke en erstatning for nettverkssegmentering, secrets management, SIEM, EDR eller klassisk tilgangsstyring.

Likevel er retningen riktig. Når agenter får skrive kode, åpne pull requests, sende meldinger, hente kundedata eller starte arbeidsflyter, må virksomheten ha et «policy før handling»-prinsipp. Ikke etterkontroll alene. Ikke bare modellkort. Ikke bare en intern retningslinje. Hver handling må kunne knyttes til agentidentitet, aktiv policy, beslutningsgrunnlag og et revisjonsspor som tåler spørsmål fra sikkerhet, ledelse og revisor.

For norske CIO-er og CISO-er bør dette bli en sjekkliste i alle agentprosjekter: Kan vi stoppe destruktive handlinger før utførelse? Kan vi kreve godkjenning per handlingstype? Kan vi se hvilken agent som gjorde hva? Kan vi skille menneske, agent og underagent i loggene? Kan vi eksportere beslutninger til egen sikkerhetsplattform? Kan vi dokumentere kontroller mot NIST AI RMF, OWASP Agentic AI Top 10, EU AI Act og SOC 2?

Agent Governance Toolkit svarer ikke på alle disse spørsmålene alene. Men Microsoft gjør det vanskeligere å late som de ikke finnes. Det er verdt en publisering i seg selv. Bedrifter som skal slippe agenter inn i produksjon, trenger en styringsmodell som ligner mer på IAM, policy engine og SRE enn på chatbot-administrasjon. Agentene er på vei inn i driftslinjen. Da må kontrollene flytte inn foran verktøykallet.

Kilder og medier

• Primærkilde: Microsoft, Agent Governance Toolkit på GitHub. https://github.com/microsoft/agent-governance-toolkit
• Kildekreditering: Microsoft.
• Thumbnail: OpenAI Image 2 / hogby.ai.