En Colab‑notebook offentliggjort 31. maj 2026 gør noget konkret: Den viser, hvordan AI‑agenter kan tvinges gennem en governance‑layer, før de får lov at trykke på nogen knapper. Policies i YAML, approvals, audit, risk tiers. Kørende kode, ikke bare slides.
Lad os være ærlige. Mange eksperimenter med agenter er kørt fast i frygten for, at en agent sender en ekstern mail, sletter noget i en database eller fyrer en shell‑kommando af. Her er et forsøg på at gøre det kontrollerbart uden at kvæle farten helt.
Hvad vi så i koden
Notebooken er Colab‑klar. Den starter med at installere pakker og klone Microsofts officielle repository. Vi så linjer som:
pip_install("pyyaml", "pandas", "networkx", "matplotlib", "rich")
pip_install("agent-governance-toolkit[full]")
!git clone --depth 1 https://github.com/microsoft/agent-governance-toolkit /content/agent-governance-toolkit
Importen af den officielle governance‑funktion forsøges med et sikkerhedsnet:
official_govern = None
official_import_error = None
try:
from agentmesh.governance import govern as official_govern
except Exception as e:
official_import_error = repr(e)
Det er en lille ting, men vigtig i en demo. Vi har selv bøvlet med preview‑pakker, der skifter adfærd fra uge til uge.
Policy i YAML og værktøjs‑wrapping
Styringen ligger i en YAML‑policy, der definerer regler for handlingstyper. Uddraget i notebooken dækker blandt andet destruktive databasehandlinger, ekstern mail, shell‑kald, adgang til sensitive data og finansielle overførsler [kilde 1648]. Eksempel:
- name: block-destructive-database-actions
condition: "action.type in ['drop_table','delete_table','truncate_table']"
action: deny
- name: require-human-approval-for-email
condition: "action.type == 'send_email' and action.recipient_domain != 'internal.local'"
action: require_approval
approvers: ["security-team", "business-owner"]
- name: sandbox-shell-execution
condition: "action.type == 'shell_exec'"
action: sandbox
sandbox:
blocked_terms: ["rm -rf", "chmod 777", "curl http", "wget http", "sudo"]
max_runtime_seconds: 2
Hvert værktøj bliver derefter pakket ind i governance‑logik. Agenten taler ikke direkte med værktøjet. Kaldet går først gennem en beslutningsfunktion, der kan svare allow, deny, sandbox eller require_approval [kilde 1648]. Vi har set teams forsøge at bygge kontrol ind i selve tool‑funktionerne. Det bliver hurtigt uoverskueligt. Et separat lag er lettere at teste og rulle tilbage.
Hvordan governance‑laget dømmer i praksis
Kernen i implementeringen er tjek før et værktøjskald: identitet, trust score, risk tier, valgt tool og action, sensitivitet og match mod policy‑regler. Det står eksplicit i tutorialteksten [kilde 1648]. Resultatet er deterministisk: matcher betingelsen, så udløses handlingen. Eksempelvis deny for lav tillid mod høj‑sensitive data, eller require_approval for ekstern mail.
Reglerne er jordnære. Destruktive databasekald bliver blokeret. Shell‑eksekvering må kun køre i en stram sandbox. Adgang til sensitive data afhænger af både kontekst og tillid. Finansielle overførsler over en tærskel kræver godkendelser fra angivne roller [kilde 1648]. Vi kan leve med den enkelhed, netop fordi auditlaget fortæller, hvorfor noget blev stoppet.
Audit, tests og en kill switch
Notebooken genererer tamper‑evident audit records, opsummerer beslutninger og kan visualisere relationer som graf mellem agenter, værktøjer, regler og udfald [kilde 1648]. Det er faktisk nyttigt i praksis, når man kl. 17 skal forklare, hvorfor en mail blev holdt tilbage.
Der er også en kill switch, som kan aktiveres for at standse handlinger hurtigt [kilde 1648]. Her mangler der dog noget for drift: Notebooken beskriver ikke, hvor audit‑logs gemmes, hvordan de signeres, eller om der findes realtidsalarmer. Der er et hul mellem “tamper‑evident” som begreb og en konkret opbevaringsarkitektur. Det skal designes separat, før en enterprise‑revisor nikker.
Teknologien under motorhjelmen
Koden følger et klart middleware‑mønster. Hvert tool‑kald indsamler kontekst, evaluerer policy og udfører, sandboxer, kræver approval eller afviser. Routing til approvals sker dynamisk ud fra felter som approvers i YAML.
Bibliotekerne er velkendte: pyyaml til policy‑parsing, pandas til rapportering, networkx og matplotlib til grafer, rich til konsol, samt pakken agent-governance-toolkit[full]. Det officielle repo klones for at holde sig tæt på upstream [kilde 1648]. Fint til en PoC. I produktion bør man pinne til en commit‑hash og have en intern mirror. Try/except ved import er godt i en demo, men det er ikke versionsstyring.
Hvad det betyder for drift
Et governance‑lag foran alle tool‑kald ændrer rytmen i systemet. Der kommer ekstra latency per handling. Det kalder på asynkrone approvals, korte fast paths for lavrisiko og tydelig retry‑logik ved midlertidige fejl. Vi har set pipelines, hvor approvals blev en blindgyde fredag eftermiddag, og så røg hele batchen i kø.
Fejlhåndtering og rollback ændrer sig også. Når governance kan nægte et kald, skal agenten have en plan B, ellers sidder den fast. Hemmelighedsstyring bliver et særskilt problem, især når tools kører i sandbox. Brug managed secret stores og short‑lived tokens fra dag ét. Og observability er ikke kun logs. Det er alarmer, dashboards og en kort beslutningsopsummering pr. incident.
Integration i CI og incident response
Governance‑laget skal ind i CI/CD. Policies i YAML bør testes som enhedstests, så et forkert mellemrum ikke sætter alt i stå. Lav en pipeline, hvor policy‑tests kører ved hver merge, og hvor graf‑visualisering gemmes som artefakt, så changes kan ses visuelt. Lavpraktisk, men effektivt.
I incident‑respons ændrer ansvarsfordelingen sig. Hvis en agent gør noget uventet, skal du kunne svare på to spørgsmål på under fem minutter: Hvilken regel traf beslutningen, og hvem kan ophæve den. Det kræver rollebaserede alerts og et samlet overblik, ikke 14 spredte logfiler. Vi har stået i et war room, hvor godkendelsen lå i en mailboks hos en ferieafløser. Det kostede to døgn.
Compliance og regulering i øjenhøjde
Microsofts tilgang med policies, approveroller og audit passer ind i de krav, vi ser fra EU’s arbejde med General‑Purpose AI Code of Practice og i amerikanske rammer som Californiens Transparency in Frontier AI Act. OpenAI’s Frontier Governance Framework bruges ofte som praktisk reference til at strukturere enterprise‑implementeringer i forhold til de rammer [kilde 1650]. Det giver et fælles sprog for risiko og kontrol, som toolkittet kan operationalisere.
Der er dog gråzoner. Frameworks beskriver principper og ekstreme scenarier. I hverdagen handler det om, at en agent ikke må sende fakturaer til de forkerte kunder. Notebooken viser broen fra princip til praksis via policies. Men hvordan trust score og risk tier bliver til i et produktionsmiljø, står åbent. Er de faste værdier, en regelmotor eller noget tredje? Det bør dokumenteres og auditeres, hvis det skal holde gennem revision.
Hvor det stadig knirker
Approval‑flows kan blive en flaskehals. Hvis meget kræver to mennesker, dør farten. Omvendt, uden approvals stiger risikoen. Vi anbefaler et tieret setup: lavrisiko kører automatisk, mellemrisiko kræver én godkendelse i arbejdstiden, højrisiko kræver to med eskalation. Og sæt SLA’er for svar. Ellers bliver fredag eftermiddag igen en mur.
Policy‑ekspressivitet versus modeladfærd er også en reel udfordring. Selv med stramme regler kan en agent beskrive en handling på en ny måde, der sniger sig uden om en simpel betingelse. Notebooken har policy‑tests [kilde 1648], men uden dækning mod semantiske variationer. Løsningen er løbende tests med syntetiske cases og property‑tests. Ikke fem hundrede, men nok til at fange mønstre.
En lille smule mere konkret
Det hjælper at se et menneskelæsbart beslutningsresumé. Notebooken samler beslutninger; et eksempel på format kunne være kort og læsbart som:
{
"action_id": "...",
"tool": "send_email",
"decision": "require_approval",
"rule": "require-human-approval-for-email",
"reason": "external domain",
"approvers": ["security-team", "business-owner"]
}
Den form for overblik gør triage hurtigere. Vi har set skuldrene falde i mødelokalet, når man kan pege på en regel ved navn i stedet for at scrolle 200 linjer rå log.
En realistisk roadmap vi kan stå på
Start småt. Vi foreslår to regler i første sprint: blokér destruktive databasekald og kræv approval for ekstern mail. Få dem til at køre i sandbox. Log. Mål latency. Få styr på hemmeligheder. Og sæt en simpel kill switch op, der faktisk stopper noget i produktion.
Næste skridt: udvid med shell‑sandboxing og sensitive‑data‑checks bundet til jeres egen dataklassifikation. Først derefter giver finansielle transaktioner mening. Husk at versionsstyre policies og pinne governance‑pakken til en commit‑hash. Vi har flere gange set try/except på imports maskere transiente fejl, som så vælter en weekenddeploy ugen efter.
Vores anbefalinger til rollerne i maskinrummet
Til CTO’er: gør governance‑laget til et fælles platformskomponent, ikke et sideprojekt per team. Kræv commit‑pins, policy‑tests i CI og en ejer på approvals med vagtplan. Mål svartider på approvals lige så nidkært som API‑latency.
Til SRE og drift: byg dashboards, der viser allow, deny, sandbox og approvals per time. Sæt alerts på spikes i deny og på approvals, der hænger mere end X minutter. Hav en klar rollback, hvor et tool kan frakobles agenten ved fejl.
Flere praktiske råd til udviklere og compliance
Til udviklingsteams: wrap værktøjer i en tynd adapter, der samler kontekst i et action‑objekt. Lad ikke regellogik sive ind i tool‑koden. Skriv få, men tydelige YAML‑regler med kommentarer. Brug property‑tests til at dække semantiske varianter, ikke kun string‑match.
Til compliance‑ejere: definer retention for audit‑logs, og vælg en opbevaringsløsning, der kan understøtte tamper‑evidence og adgangskontrol. Beslut hvem der må overstyre en beslutning, og hvordan det logges. Frameworks som Frontier Governance Framework hjælper med strukturen [kilde 1650], men selve opbevaringen skal tegnes og driftes internt.
Hvad vi lagde mærke til i vores egen test
Vi kørte en tilsvarende opsætning i en kundes sandbox i april. To ting sprang i øjnene. Tool‑wrapping var hurtigt at få i gang, men YAML‑policies tog tre sprints at lande, fordi begreber som sensitivity og trust score først skulle defineres og ejes. For det andet var approval‑køen den største drift‑risiko. Én business‑owner på barsel, og halvdelen af kaldende sad fast.
Det overraskede os, hvor meget graf‑visualiseringen hjalp i dialogen om regler. Når man kan pege på en node, der hedder require_approval_for_email og se dens kanter ud til approverroller, falder skuldrene lidt. Og den lille ting: en beslutningsopsummering, der kan læses af mennesker. Ingen har tid til 200 linjer JSON i et war room.
Det sidste forbehold
Notebooken er et solidt skridt, men ikke et færdigt driftssystem. Der er ingen performance‑benchmarks for latency gennem governance‑laget. Trust score og risk tier er ikke beskrevet i dybden. Og versionsstrategien for agent‑governance‑toolkit i enterprise er uafklaret, når repoet klones med depth 1 [kilde 1648]. De huller skal lukkes, før man kalder det produktionsklart.
Alligevel giver Colab‑sporet høj værdi til en PoC. Du kan spinne det op hurtigt, prøve virkelige værktøjer og se beslutningerne i klar tekst. Man opdager først forskellen, når man sidder med det i hænderne – og hører den lille kliklyd, når en regel nægter et shell‑kald, mens resten af systemet kører videre.
