ms-ai-architect/skills/ms-ai-engineering/references/agent-orchestration/agent-autonomy-and-control-governance.md

Agent Autonomy and Control - Governance Framework

Last updated: 2026-06-24 Status: GA Category: Agent Orchestration & Automation Type: reference Source: https://learn.microsoft.com/azure/foundry/guardrails/guardrails-overview

---

Innhold

• Introduksjon
• Kjernekomponenter
• Arkitekturmønstre
• Beslutningsveiledning
• Integrasjon med Microsoft-stakken
• Offentlig sektor (Norge)
• Kostnad og lisensiering
• For arkitekten (Cosmo)
• Kilder og verifisering

Introduksjon

Autonome AI-agenter representerer et paradigmeskifte fra deterministisk programvarelogikk til probabilistisk beslutningstaking. Når agenter får tilgang til eksterne systemer, kan modifisere data, og tar selvstendige beslutninger, introduseres operasjonelle risikoer som krever nye styringsmekanismer. Et robust governance framework balanserer autonomi mot kontroll — det lar agenter operere effektivt innenfor definerte sikkerhetssoner samtidig som kritiske handlinger undergis menneskelig godkjenning.

Microsoft tilbyr et flerlags kontrollrammeverk som spenner fra deterministisk workflow-styring til Human-in-the-Loop (HITL) godkjenninger og runtime guardrails. Rammeverket dekker hele agent-livssyklusen — fra design og utvikling til deployment, monitorering og compliance. Ved å implementere graduated autonomy levels kan organisasjoner minimere blast radius for agentfeil samtidig som de opprettholder nødvendig smidighet for forretningsverdien.

Governance for agent-autonomi er ikke en binær on/off-switch. Det er et spekter av kontrolltiltak tilpasset agent-type, kontekst og risikoprofil. Retrieval-agenter (kun lesing) krever primært datakontroll og audit logging. Task-based agents (read + write) trenger omfattende autorisasjon og transaksjonsovervåking. Fully autonomous agents (multi-turn reasoning) krever alle tre aspekter — robuste data-grenser, validering av integriteten, og uavhengige guardrails — med høyeste grad av oversight.

Kjernekomponenter

Kontrollnivåer i Microsoft Agent-stakken

Kontrollnivå	Beskrivelse	Anvendelsesområde	Microsoft-verktøy
Deterministisk lag	Regelbasert, streng sekvensiell logikk for kritiske operasjoner	Finansielle transaksjoner, datasletting, compliance-krav	Foundry Workflows, Microsoft Agent Framework Workflows, Copilot Studio Topics
Hybrid (intercept) lag	AI-fleksibilitet med intervensjonssjekker og human-in-the-loop	Medium-risiko prosesser, approval workflows, eskaleringslogikk	HITL i Agent Framework, Foundry Agent Service approval policies, Copilot Studio confirmation nodes
AI orchestrator lag	Full generativ autonomi innenfor guardrails	Low-risk Q&A, informasjonshenting, rutineoppgaver	Generative Orchestration, Tool approval modes, System message constraints

Human-in-the-Loop (HITL) mekanismer

Mekanisme	Formål	Konfidensgrad
Function approval	Krever bruker/admin godkjenning før tool execution	Verified (Microsoft Learn)
AgentRequestInfoResponse	Pause workflow for feedback eller approval	Verified (Agent Framework docs)
Approval modes	always_require, never_require, conditional	Verified (Python @tool decorator)
Handoff orchestration	Spesialisert for komplekse multi-agent HITL-scenarier	Verified (Agent Framework)

Guardrails og intervention points

Guardrails opererer ved fire intervention points i agent execution lifecycle:

1. User input (prompt) — Filtrer ondsinnede prompts, sensitive data før prosessering
2. Tool call (Preview) — Valider tool invocations for injection attacks
3. Tool response (Preview) — Inspiser tool output for compliance og safety
4. Output (completion) — Content moderation, plagiarism checks før levering

Risk categories som detekteres:

• Hate, Sexual, Self-harm, Violence
• User prompt attacks, Indirect attacks
• Protected material (code + text)
• Personally identifiable information (PII)
• Groundedness, Spotlighting (preview), Task Adherence (preview)

Actions:

• Annotate — Logg risikodeteksjon uten å blokkere (kun modeller)
• Annotate and block — Blokker og logg (modeller + agenter)

Arkitekturmønstre

Mønster 1: Graduated Autonomy Pattern

Prinsipp: Agenter starter med minimal autonomi og øker tillit basert på suksessrate og kontekst.

from agent_framework import ChatAgent, tool

# Read-only operations: full autonomy
@tool
def get_account_balance(account: str) -> str:
    """Check account balance."""
    return f"Account {account} balance: $5,432.10 USD"

# Write operations: approval required
@tool(approval_mode="always_require")
def transfer_funds(from_account: str, to_account: str, amount: float) -> str:
    """Transfer money between accounts."""
    return f"Transferred {amount} from {from_account} to {to_account}"

# High-risk operations: deterministic workflow
# Handled outside agent via Azure Durable Functions

Fordeler:

• Minimerer blast radius for nye agenter
• Tillater iterativ tillitsoppbygging
• Tydelig risikosegmentering

Ulemper:

• Krever nøye kategorisering av operasjoner
• Kan introdusere latency ved mange approval checkpoints
• Kompleksitet i grensetilfeller (hva er "medium-risk"?)

---

Mønster 2: Layered Orchestration with Escape Hatches

Prinsipp: Kombiner deterministisk orchestration for critical path med AI-drevet reasoning for adaptive tasks. Implementer escape hatches for menneskelig override.

from agent_framework import SequentialBuilder, HandoffBuilder

# Sequential orchestration with HITL for subset of agents
workflow = (
    SequentialBuilder()
    .participants([triage_agent, refund_agent, order_agent])
    .with_request_info(agents=[refund_agent])  # Only refund_agent requires approval
    .build()
)

# AgentRequestInfoResponse allows feedback or approval
# - Feedback: AgentRequestInfoResponse.from_messages(...)
# - Approval: AgentRequestInfoResponse.approve()

Fordeler:

• Fleksibilitet uten å ofre kontroll
• Granular control over hvilke agenter som krever oversight
• Effektiv håndtering av eskalering

Ulemper:

• Krever nøye design av handoff-logikk
• Overhead i multi-agent koordinering
• Testing blir mer kompleks (må simulere approval flows)

---

Mønster 3: Independent Governance Agent

Prinsipp: Dedikert "governance agent" overvåker andre agenters handlinger på tvers av systemet og kan blokkere, eskalere eller logge avvik.

Arkitektur:

• Coordinator agent — Monitorer task execution, eskalerer anomalier til mennesker
• Continuous tracing — Sporer agent-interaksjoner på tvers av digital ecosystem
• Threshold-based alerting — Automatisk varsling ved uvanlige mønstre (Azure Monitor Alerts)

Microsoft-verktøy:

• Azure Application Insights for tracing (agent-framework SDK)
• Microsoft Defender for Cloud AI protection
• Sentinel integration for SOC workflows

Fordeler:

• Separation of concerns (governance er isolert fra business logic)
• Multi-layered forsvar
• Sentralisert policy enforcement

Ulemper:

• Ekstra infrastruktur og vedlikeholdskostnader
• Risiko for false positives som blokkerer legitime operasjoner
• Krever tuning av terskelverdier

Beslutningsveiledning

Når bruke HITL vs. deterministisk workflow

Scenario	Anbefaling	Begrunnelse
Finansielle transaksjoner > 10 000 NOK	HITL (approval required)	Compliance + risikominimering
Sletting av produksjonsdata	Deterministisk workflow	Zero tolerance for feil
Kundeservice-draft (e-post/chat)	Hybrid: AI-generert + human review	Balanse mellom effektivitet og kvalitet
Informasjonshenting fra knowledge base	Full autonomi (ingen approval)	Low risk, high volume
Oppdatering av CRM-records	HITL (conditional approval basert på felt-type)	Kritiske felt (e.g., kontaktinfo) krever approval

Vanlige feil

Feil	Konsekvens	Mitigering
Over-autonomi for nye agenter	Uventede sideeffekter, datalekkasje, compliance-brudd	Start med approval_mode="always_require" for alle write-operations, reduser gradvis
Ingen escape hatches	Agent-feil blir irreversible	Implementer pause/resume capabilities, circuit breakers, human override
Hardkodede secrets i tool definitions	Sikkerhetsrisiko	Bruk Azure Key Vault, managed identities, short-lived tokens
Manglende audit trail	Kan ikke spore beslutninger ved incidents	Logg alle tool calls med conversation ID, user identity, timestamp (Azure Monitor Logs)
Batching av sensitive operasjoner	Bruker godkjenner uten å forstå full scope	Granular approval: én approval per kritisk handling

Røde flagg (når stoppe deployment)

• Agent utfører write-operations uten approval i produksjon
• Ingen logging av tool executions
• Guardrails konfigurert med kun "Annotate" (ikke "Block") for high-risk content
• Agent har tilgang til mer data enn nødvendig (brudd på least privilege)
• Ingen mekanisme for å disable agent raskt ved incident

Integrasjon med Microsoft-stakken

Microsoft Foundry

Guardrails:

• Default: Microsoft.DefaultV2 guardrail
• Agents arver guardrails fra model deployment (hvis ikke eksplisitt overskrevet)
• Agent-guardrails overskriver model-guardrails (viktig for agent-specific policies)
• Tool call/response intervention points (preview) — kun for agenter

AI Gateway:

• Powered by Azure API Management
• Sentralisert kontrollpunkt for policy enforcement
• Token limits, usage quotas per project/agent
• Pause/resume capabilities for external agents

Foundry Agent Service:

• Managed orchestration med innebygd sikkerhet
• Memory storage (Azure Cosmos DB for NoSQL)
• Conversation state management med access controls

Microsoft Agent Framework

Workflows:

• Sequential, Concurrent, Group Chat, Magentic orchestrations
• HITL via with_request_info() på builder
• Function approval integrasjon (FunctionApprovalRequestContent)

Durable Agents (Azure Functions):

• Deterministic multi-agent orchestrations
• Human-in-the-loop med serverless hosting (cost-efficient)
• Automatic conversation state management
• Pause workflows for days/weeks (no compute cost during wait)

AG-UI Protocol: (Verified MCP 2026-04)

• Backend tool rendering med approval support
• Bidirectional middleware for client/server approval handling
• request_approval tool call pattern
• C# implementering: ApprovalRequiredAIFunction klasse, bidirectional middleware
• Python implementering: @tool(approval_mode="always_require") dekoratør, AgentFrameworkAgent(require_confirmation=True)

Microsoft Copilot Studio

Generative Orchestration:

• Konfigurerbar kontroll: AI kan/ikke kan override authored topics
• Explicit confirmation nodes i topics
• Trigger-based approval workflows

Security:

• Automatic security scans
• Agent runtime protection monitoring
• DLP policy integration

Microsoft Entra Agent ID

Identity management:

• Separat identity for agenter (ikke brukerkonto)
• RBAC/ABAC for tool permissions
• Conditional Access policies basert på agent context og risk
• Lifecycle workflows for agent provisioning/deprovisioning

Microsoft 365 Admin Center & Agent 365

Unified control plane:

• Agent Registry: Alle agenter i organisasjonen (inkl. shadow agents)
• Centralized visibility og governance
• Drill-down til sikkerhetsprodukter (Defender, Sentinel)

Offentlig sektor (Norge)

Forvaltningsloven og delegation av myndighet

Utfordring: Kan en AI-agent fatte vedtak på vegne av en offentlig myndighet?

Svar: Nei, ikke uten eksplisitt lovhjemmel. Forvaltningsloven krever at vedtak fattes av kompetent myndighet (typisk en person med delegert myndighet). Agenter kan forberede beslutningsgrunnlag, men det må alltid være en menneskelig beslutningstaker som formelt fatter vedtaket.

Konsekvens for governance:

• Alltid HITL for vedtaksforberedelse — Agent leverer utkast, saksbehandler godkjenner
• Audit trail — Dokumenter agentens bidrag og saksbehandlers vurdering
• Transparency — Borger skal få vite at AI er brukt i saksbehandlingen (Forvaltningsloven § 25 begrunning)

AI-loven (EU AI Act)

Risikoklassifisering: High-risk AI systems (inkl. mange offentlig sektor use cases) krever:

• Human oversight (Article 14) — "meaningful human control"
• Logging capabilities (Article 12) — full traceability
• Robustness og accuracy requirements

Implementering i Microsoft-stakk:

• HITL for high-risk decisions
• Azure Monitor Logs for full audit trail (retain 90+ dager)
• Foundry evaluators for quality assurance

GDPR og datasuverenitet

Automated decision-making (Article 22):

• Borgere har rett til å ikke bli underlagt automated decision-making med legal/significant effects
• Krever explicit consent ELLER nødvendig for contract/legal obligation
• Rett til human intervention, express views, contest decision

Microsoft compliance:

• Azure regions i Norge (Norway East, Norway West) for dataresidency
• EU Data Boundary commitment
• Granular access controls via Entra ID

Utredningsinstruksen

Krav til utredning av AI-løsninger:

• Nyttevurdering — Dokumenter forventet gevinst vs. risiko
• Konsekvensutredning — Hvordan påvirker AI-agent tjenestekvalitet, likhet, privacy?
• DPIA (Data Protection Impact Assessment) — Obligatorisk for high-risk processing

Governance-implikasjoner:

• Dokumenter autonomy levels og control mechanisms i DPIA
• ROS-analyse (NSM-metode) inkluderer agent-spesifikke trusler (prompt injection, data leakage)
• Gevinstrealiseringsplan inkluderer kostnader for compliance og oversight

Kostnad og lisensiering

Prismodeller for governance-komponenter

Komponent	Prismodell	Estimat (NOK/måned)
Foundry Agents	Per interaction (input/output tokens)	Varierer: GPT-4o ~0.02 NOK/1K tokens
Azure Application Insights	Per GB ingested + retention	~200-2000 NOK for small-medium agent fleet
Azure API Management (AI Gateway)	Per gateway instance + calls	Developer: ~400 NOK, Standard: ~6000 NOK
Azure Monitor Alerts	Per alert rule + notifications	~10 NOK per rule, email free
Microsoft Defender for Cloud	Per resource (AI protection add-on)	~200-500 NOK per subscription
Entra ID P1/P2	Per user (for Conditional Access on agents)	P1: ~60 NOK/user, P2: ~90 NOK/user

Optimaliseringstips:

• Sampling for logging — 100% logging i dev/test, 10-20% i prod (med full logging ved errors)
• Guardrail-nivåer — Bruk Low threshold for non-critical content, High for sensitive domains
• Token limits per agent — Forhindre runaway costs ved feil i agent logic
• PTU (Provisioned Throughput Units) — For høyvolum agenter, vurder PTU vs. pay-as-you-go

Lisensiering

Microsoft Agent Framework: Open source (MIT-lisens), ingen lisensiering Microsoft Foundry: Pay-as-you-go (consumption-based), ingen upfront lisens Copilot Studio: Inkludert i Microsoft 365 Copilot lisens (18 000 NOK/user/år), eller standalone (~2000 NOK/user/år)

For arkitekten (Cosmo)

Spørsmål å stille klienten

1. Autonomy maturity: "Hvor moden er organisasjonen med AI? Er dette første agent, eller har dere erfaring med autonomous systems?"

   • Hvorfor: Bestemmer hvor konservativ governance-politikken bør være

2. Risk appetite: "Hva er worst-case scenario hvis agenten gjør noe feil? Økonomisk tap, omdømme, safety?"

   • Hvorfor: Kalibrerer HITL vs. full autonomi

3. Compliance-krav: "Er dette en high-risk use case i henhold til AI Act? Involverer det vedtak/beslutninger som påvirker individer?"

   • Hvorfor: Bestemmer om HITL er lovpåkrevd, ikke bare best practice

4. Incident response readiness: "Har dere en plan for å raskt disable agenten hvis noe går galt? Hvem har ansvaret?"

   • Hvorfor: Escape hatches må være på plass før deployment

5. Data sensitivity: "Hvilke data skal agenten ha tilgang til? Er det personopplysninger, forretningshemmeligheter, sikkerhetsgradert info?"

   • Hvorfor: Least privilege + PII-deteksjon i guardrails

6. Operational context: "Kjører agenten 24/7, eller kun i kontortid? Er det mennesker tilgjengelig for approvals hele tiden?"

   • Hvorfor: HITL fungerer dårlig hvis ingen kan approve (vurder async approval workflows)

7. Volume og latency: "Hvor mange interaksjoner forventer dere per dag? Hva er akseptabel responstid?"

   • Hvorfor: Approval workflows introduserer latency; high-volume kan kreve mer autonomi

8. Existing governance: "Har dere eksisterende approval workflows (e.g., i ServiceNow, Power Automate)? Kan vi integrere?"

   • Hvorfor: Unngå å bygge parallelle systemer; bruk det som finnes

Fallgruver å unngå

Fallgruve	Hvorfor det skjer	Hvordan unngå
"Vi trenger ikke HITL, modellen er veldig god"	Overconfidence i modell-capabilities	Forklar probabilistic nature of LLMs; selv GPT-4 gjør feil 1-5% of the time
"Vi legger til guardrails senere"	Pressure for rask time-to-market	Security/governance må være by-design, ikke bolt-on; mye vanskeligere å fikse i prod
"Vi loggger alt til Application Insights"	Compliance-krav forstås som "bare logging"	Logging ≠ governance; trenger også preventive controls (guardrails, HITL)
"Agenten har read-only tilgang, så det er trygt"	Undervurderer data leakage risk	Read-only agent kan likevel lekke PII via output; trenger content safety på output
"Vi bruker samme guardrail for alle agenter"	One-size-fits-all tenking	Hver agent-type har unik risikoprofil; customer-facing vs. internal, read vs. write

Anbefalinger per modenhetsnivå

Level 1 (First agent):

• Start med HITL (approval_mode="always_require") for ALL tool calls
• Bruk Microsoft.DefaultV2 guardrails uten customization
• Logging: 100% av alle interactions i Application Insights
• Deploy kun i dev/test; ingen prod før security review

Level 2 (Expanding use):

• Graduated autonomy: Approval kun for write-operations
• Custom guardrails med blocklists for organisasjonens sensitive termer
• Implementer AI Gateway for sentralisert policy enforcement
• Monthly review av audit logs for policy tuning

Level 3 (Mature agent ecosystem):

• Multi-layered orchestration (deterministisk + hybrid + AI orchestrator)
• Governance agents for continuous monitoring
• Automated evaluation pipelines (CI/CD integration)
• Red teaming exercises hver quarter
• Agent Registry med full lifecycle management

Kilder og verifisering

Verified (MCP Research - microsoft-learn):

1. Human-in-the-Loop with AG-UI Confidence: High — Detaljert dokumentasjon av HITL-implementering i Microsoft Agent Framework

2. Microsoft Agent Framework Workflows - Human-in-the-Loop Confidence: High — with_request_info(), AgentRequestInfoResponse patterns

3. Process to build agents across your organization Confidence: High — Tool boundaries, human-in-the-loop mandates, compliance frameworks

4. Guardrails and controls overview in Microsoft Foundry Confidence: High — Intervention points, risk categories, agent vs. model guardrails

5. Secure AI agents at scale using Microsoft Agent 365 Confidence: High — Agent Registry, Entra Agent ID, Conditional Access

6. Responsible AI in Azure workloads Confidence: High — Agentic AI safeguards, escape hatches, coordinator agents

7. Durable Agent Features Confidence: High — Deterministic orchestrations, HITL with serverless hosting

8. Apply generative orchestration capabilities (Copilot Studio) Confidence: High — Three-layer control (deterministic, hybrid, AI orchestrator)

9. Artificial Intelligence Security - Apply least privilege for agent functions Confidence: High — RBAC, token-based auth, network segmentation, monitoring

Baseline (Model Knowledge):

• Forvaltningsloven § 28 (delegasjon av myndighet) — Baseline, men verifisert via lovdata.no
• AI Act Article 14 (human oversight) — Baseline, publisert EU-regulering
• GDPR Article 22 (automated decision-making) — Baseline, etablert lov

Confidence markers per seksjon:

Seksjon	Confidence	Begrunnelse
Kontrollnivåer	Verified	Direkte fra Microsoft Learn (Copilot Studio generative orchestration)
HITL mekanismer	Verified	Agent Framework docs + code samples
Guardrails	Verified	Microsoft Foundry docs
Graduated Autonomy Pattern	Baseline	Syntetisert fra best practices, ikke eksplisitt Microsoft pattern
Layered Orchestration	Verified	Agent Framework workflow docs
Independent Governance Agent	Verified	Responsible AI docs (coordinator agents)
Forvaltningsloven	Baseline	Juridisk tolkning, ikke Microsoft-spesifikk
AI Act compliance	Baseline	EU-regulering, ikke Microsoft-implementering
Kostnadsestimater	Baseline	Azure pricing calculator, ikke verifisert i docs