# Agent Autonomy and Control - Governance Framework

**Last updated:** 2026-04
**Status:** GA
**Category:** Agent Orchestration & Automation

---

## 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)

**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.

```python
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.

```python
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

### Azure AI 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) |
|-----------|------------|---------------------|
| **Azure AI 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
**Azure AI 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](https://learn.microsoft.com/en-us/agent-framework/integrations/ag-ui/human-in-the-loop)
   Confidence: High — Detaljert dokumentasjon av HITL-implementering i Microsoft Agent Framework

2. [Microsoft Agent Framework Workflows - Human-in-the-Loop](https://learn.microsoft.com/en-us/agent-framework/user-guide/workflows/orchestrations/human-in-the-loop)
   Confidence: High — `with_request_info()`, `AgentRequestInfoResponse` patterns

3. [Process to build agents across your organization](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/build-secure-process)
   Confidence: High — Tool boundaries, human-in-the-loop mandates, compliance frameworks

4. [Guardrails and controls overview in Microsoft Foundry](https://learn.microsoft.com/en-us/azure/ai-foundry/guardrails/guardrails-overview)
   Confidence: High — Intervention points, risk categories, agent vs. model guardrails

5. [Secure AI agents at scale using Microsoft Agent 365](https://learn.microsoft.com/en-us/security/security-for-ai/agent-365-security)
   Confidence: High — Agent Registry, Entra Agent ID, Conditional Access

6. [Responsible AI in Azure workloads](https://learn.microsoft.com/en-us/azure/well-architected/ai/responsible-ai)
   Confidence: High — Agentic AI safeguards, escape hatches, coordinator agents

7. [Durable Agent Features](https://learn.microsoft.com/en-us/agent-framework/user-guide/agents/agent-types/durable-agent/features)
   Confidence: High — Deterministic orchestrations, HITL with serverless hosting

8. [Apply generative orchestration capabilities (Copilot Studio)](https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/generative-orchestration)
   Confidence: High — Three-layer control (deterministic, hybrid, AI orchestrator)

9. [Artificial Intelligence Security - Apply least privilege for agent functions](https://learn.microsoft.com/en-us/security/benchmark/azure/mcsb-v2-artificial-intelligence-security)
   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 | Azure AI 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 |
