# Microsoft Entra Agent ID — Zero Trust for AI-agentidentiteter

**Kategori:** AI Security Engineering
**Sist oppdatert:** 2026-04 | Verified: MCP 2026-04
**Status:** Public Preview (annonsert Ignite november 2025, utvidet preview; opt-out er midlertidig — vil bli obligatorisk for nye agenter) *(Verified MCP 2026-04)*
**Målgruppe:** Arkitekter som skal sikre AI-agenter med dedikerte identiteter og Zero Trust-prinsipper

## Introduksjon

Etter hvert som AI-agenter blir en integrert del av virksomhetens arbeidsprosesser, oppstår et fundamentalt sikkerhetsproblem: tradisjonelle identitetsmodeller er ikke designet for autonome programvaresystemer som handler på egenhånd, opprettes og slettes dynamisk, og kan proliferere ukontrollert — kjent som «agent sprawl».

**Microsoft Entra Agent ID** er Microsofts svar på dette. Det er et dedikert identitets- og sikkerhetsrammeverk for AI-agenter, bygget på Entra ID-plattformen. Løsningen gir agenter førsteklasses identitetskonstrukter — på linje med det mennesker og arbeidsbelastningsidentiteter har — og utviderer Zero Trust-prinsippene til autonome AI-systemer.

Entra Agent ID er en del av **Microsoft Agent 365**, Microsofts kontrollplan for agenter på tvers av virksomheten.

### Hvorfor agentidentiteter er annerledes enn app-identiteter

| Egenskap | Tradisjonell app-identitet (service principal) | Agentidentitet |
|----------|------------------------------------------------|----------------|
| **Livsløp** | Langsiktig, stabil | Dynamisk — kan opprettes/slettes tusenvis av ganger per dag |
| **Opprettelse** | Manuell, administrator-styrt | Automatisk (via platform, bruker, API) |
| **Atferd** | Forutsigbar, deterministisk | Adaptiv, probabilistisk |
| **Risiko** | Begrenset til definert logikk | Kan handle uventet pga. AI-beslutninger |
| **Skala** | Typisk begrenset antall | Potensielt millioner av instanser |

Agentidentiteter omfavner denne dynamiske naturen med tilpassede sikkerhetskontroller: masseopprettelse, konsistente policyer, og ryddig avvikling uten etterlatte credentials.

## Hva er Microsoft Entra Agent ID?

Entra Agent ID er et identitets- og sikkerhetsrammeverk med tre kjernefunksjoner:

### 1. Registrere og administrere agenter
- **Agentidentiteter:** Oppretter og administrerer agentidentiteter som individuelle instanser med foreldre-barn-relasjoner til blueprints
- **Agent Registry:** Sentralisert metadatarepository for alle agenter i tenanten

### 2. Styre agentidentiteter og livsløp
- **Identity Governance for agenter:** Livsløpsadministrasjon, tilgangstildeling, og compliance-rapportering

### 3. Beskytte agenters tilgang til ressurser
- **Global Secure Access for agenter:** Nettverksnivå-sikkerhet og Zero Trust-tilgang for agentkommunikasjon
- **Conditional Access for agenter:** Policy-baserte tilgangskontroller og risikobasert autentisering
- **Identity Protection for agenter:** Sanntidsdeteksjon av risiko og automatisert respons

## Kjernekomponenter og begreper

### Agentidentitet (Agent Identity)

En agentidentitet er en **spesialisert service principal** i Microsoft Entra ID, designet for AI-agenter. Nøkkelkjennetegn:

- Har unike identifikatorer (object ID og app ID — alltid lik)
- **Ingen passord eller credentials** — autentiseres utelukkende via access tokens utstedt til plattformen agenten kjører på
- Skilt fra arbeids-, kunde- og arbeidsbelastningsidentiteter
- Underlagt strengere restriksjoner enn vanlige service principals (blokkerte høyprivilegerte roller)

**To autentiseringsscenarioer:**

| Scenario | Beskrivelse | Eksempel |
|----------|-------------|---------|
| **Attended (delegert)** | Agenten handler på vegne av en bruker med delegerte tillatelser | Support-agent laster ned brukerens dokumenter med brukerens samtykke |
| **Unattended (autonom)** | Agenten handler med sin egen autoritet som applikasjonsidentitet | Overvåkingsagent leser logger uten menneskelig intervensjon |

### Agent Identity Blueprint

Et blueprint er den **gjenbrukbare styringsmalen** som alle agentidentiteter opprettes fra. Det tilsvarer en *type* eller *klasse* av agenter.

**Blueprint-kapabiliteter:**

1. **Typeklassifisering:** Definerer agentens kategori (f.eks. «Contoso Sales Agent»). Muliggjør:
   - Bruk av Conditional Access-policyer på alle agenter av denne typen
   - Deaktivering/revokering av tillatelser for alle instanser samtidig
   - Revisjon og styring i skala

2. **Identitetsopprettelsesautoritet:** Plattformer som oppretter agentidentiteter autentiserer via blueprintet med OAuth-credentials (client secrets, sertifikater, eller federated credentials/managed identities)

3. **Runtime-autentiseringsplattform:** Vertstjenesten bruker blueprintet ved runtime for å hente access tokens til agentidentiteter

### Agent Registry

Agent Registry er et sentralisert metadatarepository for alle registrerte agenter i organisasjonen. Det løser problemet med «agent sprawl»:

**Kapabiliteter:**
- Samlet oversikt over alle deployerte agenter — Microsoft-plattformer *og* tredjepartsøkosystemer
- Innebygde og tilpassede kontroller via **agent collections** og policyer
- Rollebasert observabilitet med dedikerte Entra-roller (`Agent ID Administrator`, `Agent ID Developer`, `Agent Registry Administrator`)
- Detaljert logging og rapportering (sign-in og audit logs)

**Tilgang:** Microsoft Entra admin center → Agent Identities-fanen, og Microsoft 365 admin center via Agent 365.

### Agent Users (agentbrukere)

For scenarioer der agenter må samhandle med systemer som krever brukerobjekter (f.eks. Outlook, Teams), tilbyr Entra Agent ID **agent users** som et sekundært identitetsalternativ. En agent user er et bruker-objekt med de fleste brukeregenskaper (manager, UPN, foto), som gjør det kompatibelt med systemer med hard avhengighet til brukerobjekter.

## Zero Trust-prinsipper for agenter

De tre Zero Trust-prinsippene — *Verify explicitly*, *Use least privilege*, *Assume breach* — anvendes spesifikt for AI-agenter:

### Verify explicitly — Verifiser eksplisitt

Alle agentforespørsler autentiseres og autoriseres basert på fullstendige datapunkter:

- **Agentidentitet:** Hvem er agenten? (via Entra Agent ID)
- **Blueprint-tilknytning:** Hvilken type agent er det?
- **Risikoscore:** Viser agenten avvikende atferd? (via Identity Protection for agents)
- **Nettverkskontekst:** Kommuniserer agenten via godkjente kanaler? (via Global Secure Access)

**Conditional Access for agenter** er nøkkelen her — den evaluerer agenters tilgangsforespørsler på samme måte som for menneskelige brukere, men med agentspesifikk logikk. *(Verified MCP 2026-04)*

**Scoping-muligheter:** Policyer kan scopes til: alle agentidentiteter i tenanten; spesifikke agentidentiteter (object ID); agentidentiteter basert på custom security attributes; agentidentiteter gruppert etter blueprint; alle agent users.

**Conditions:** Agent risk (high/medium/low) fra Identity Protection er tilgjengelig som condition.

**Viktig:** CA gjelder IKKE for agent identity blueprint → Graph-kall (blueprint creation) eller intermediary token exchange. CA gjelder for agent identity → resource og agent user → resource flows. *(Verified MCP 2026-04)*

### Use least privilege — Minste privilegium

Entra Agent ID håndhever minste privilegium strukturelt:

**Blokkerte rettigheter for agenter (kan IKKE tildeles):**
- `Global Administrator`, `Privileged Role Administrator`, `User Administrator`
- Microsoft Graph-tillatelser: `Application.ReadWrite.All`, `RoleManagement.ReadWrite.All`, `User.ReadWrite.All`, `Directory.AccessAsUser.All`

**Tildeling etter behov:**
- **Azure RBAC-roller:** For tilgang til Azure-ressurser (Key Vault, Storage, etc.) — alltid på ressurs- eller ressursgruppe-nivå
- **Entra-roller (lavprivilegerte):** F.eks. `Directory Readers`, `Global Reader` — kun der nødvendig
- **Delegerte Graph-tillatelser:** For user-centric scenarioer med brukersamtykke (f.eks. `Mail.Read`, `Files.Read`)
- **Graph app-tillatelser:** For autonome scenarioer — kun smale, ikke-blokkerte tillatelser

**Tilgangspakker (Agent Access Packages):** Forhåndsdefinerte tilgangspakker som agenter kan tildeles, som forenkler riktig tilgangstildeling i skala.

### Assume breach — Anta brudd

Entra Agent ID tilbyr flere lag for å begrense skadeomfanget ved kompromittering:

- **Identity Protection for agenter:** Sanntidsdeteksjon av risikabel agentaktferd (tilgang til ukjente ressurser, høyt antall mislykkede innlogginger)
- **Automatisert respons:** Risikobasert Conditional Access kan blokkere agenter umiddelbart ved detektert risiko
- **Livsløpsworkflows:** Tilgang fjernes automatisk når agentens livsløp er over — ingen foreldreløse credentials
- **Audit logging:** All agentaktivitet logges til Microsoft Entra og er synlig i admin center

## Agent Registry — Livsløpsadministrasjon

Agent Registry fungerer som organisasjonens «agentkataster» og muliggjør strukturert livsløpsadministrasjon:

### Livsløpsfaser

```
Opprettelse → Registrering → Aktiv bruk → Governance-review → Avvikling
     ↓              ↓              ↓                ↓               ↓
Blueprint    Agent Registry   Conditional     Sponsorship/     Sletting av
opprettes    metadata         Access         Access reviews    identitet +
             tilordnes        håndheves      og recertify      credentials
```

### Governance-funksjoner

- **Sponsorship:** Hver agent kan ha en ansvarlig eier/sponsor som er ansvarlig for agentatferd og tilgangsstyring. Hvis sponsor forlater organisasjonen, overføres sponsorship automatisk til managers. *(Verified MCP 2026-04)*
- **Access packages for agenter:** Forhåndsdefinerte tilgangspakker med security group memberships, Graph app-tillatelser og Entra-roller. Agenter kan be om access packages programmatisk (via accessPackageAssignmentRequest), sponsor kan be på vegne av agent, eller admin kan direkte tildele. *(Verified MCP 2026-04)*
- **Access reviews:** Regelmessig gjennomgang av agenttilganger — over-privilegerte agenter identifiseres. Når access package nærmer seg utløp, varsles sponsor som kan forlenge eller la det utløpe.
- **Lifecycle workflows:** Automatisert opprydding — f.eks. fjern tilgang etter prosjektslutt. Workflows inkluderer oppgaver for å varsle cosponsors og managers om sponsorskifte.
- **Agent collections:** Grupper agenter logisk (etter miljø, team, formål) og anvend policyer på samlingen

### Registrering av agenter

Agenter kan registreres i Agent Registry på tre måter:
1. **Automatisk** (Microsoft-plattformer som Foundry og Copilot Studio)
2. **Via API** (egenutviklede agenter)
3. **Manuelt** (tredjepartsagenter uten native integrasjon)

## Workload Identities vs. Agentidentiteter

Entra Agent ID introduserer et tydelig skille mellom identitetstyper:

| Identitetstype | Designet for | Livsløp | Opprettelsesmåte |
|----------------|-------------|---------|-----------------|
| **Brukeridentitet** | Mennesker | Langsiktig | Manuell (HR-prosess) |
| **Service principal / Managed Identity** | Tradisjonelle applikasjoner og tjenester | Stabilt, applikasjonslivsløp | Manuell/IaC |
| **Agentidentitet** | AI-agenter | Dynamisk, kan være kort-livet | Automatisk via platform |

**Managed Identity vs. Agentidentitet for AI-agenter:**

Managed Identity (system- eller user-assigned) passer fortsatt godt for:
- AI-tjenester som *verter* agenter (f.eks. Azure AI Foundry-prosjektet selv)
- Infrastruktur-til-tjeneste-kommunikasjon (Foundry → Azure OpenAI)

Agentidentitet (Entra Agent ID) passer bedre for:
- Selve AI-agenten som handler autonomt
- Scenarioer der agenter opprettes/slettes dynamisk
- Der man trenger individuelle audit trails per agent
- Multi-agent-arkitekturer med agent-til-agent-kommunikasjon (A2A)

## Integrasjon med Azure AI Foundry

Azure AI Foundry er dypt integrert med Entra Agent ID og administrerer agentidentiteter automatisk gjennom agentens livsløp.

### Automatisk provisjonering

Når du oppretter din **første agent i et Foundry-prosjekt**, oppretter systemet automatisk:
1. Et standard **agent identity blueprint** for prosjektet
2. En standard **agentidentitet** for prosjektet

### Delt prosjektidentitet (under utvikling)

Alle upubliserte agenter i samme prosjekt deler én felles identitet. Dette:
- Forenkler tillatelsesadministrasjon i utviklingsfasen
- Reduserer identitetsspredning under eksperimentering
- Gir utviklere autonomi uten å konfigurere nye tillatelser for hver agent

### Distinkt agentidentitet (ved publisering)

Når en agent publiseres, opprettes automatisk:
- Et dedikert **agent identity blueprint** knyttet til agentapplikasjonen
- En unik **agentidentitet** med separat audit trail

**Viktig:** Ved publisering må RBAC-tillatelser **tildeles på nytt** til den nye identiteten.

### Verktøyautentisering i Foundry

Foundry-agenter bruker agentidentiteten for å autentisere mot downstream-verktøy og tjenester:

```http
# Konfigurer MCP-verktøy med agentidentitetsautentisering
PUT https://management.azure.com/subscriptions/{sub}/resourceGroups/{rg}/providers/
    Microsoft.CognitiveServices/accounts/{account}/projects/{project}/connections/{name}
    ?api-version={version}

{
  "properties": {
    "authType": "AgenticIdentityToken",
    "category": "RemoteTool",
    "target": "https://your-mcp-server.example.com",
    "audience": "https://storage.azure.com"
  }
}
```

**Støttede verktøy med agentidentitetsautentisering:**
- **Model Context Protocol (MCP):** Agenten bruker identiteten til å autentisere mot MCP-servere
- **Agent-to-Agent (A2A):** Sikker kommunikasjon mellom agenter via agentidentiteter

### Tildele RBAC til Foundry-agentidentitet

```bash
# Hent agentIdentityId fra Foundry-prosjektets JSON-visning i Azure Portal
# Tildel kun nødvendig tilgang på ressursnivå

az role assignment create \
  --role "Storage Blob Data Reader" \
  --assignee <agentIdentityId> \
  --scope /subscriptions/{sub}/resourceGroups/{rg}/providers/
          Microsoft.Storage/storageAccounts/{storage-account}
```

## Integrasjon med Copilot Studio

Copilot Studio integrerer med Entra Agent ID i preview, og gir agenter automatiske identiteter ved aktivering.

### Aktivering

Entra Agent ID for Copilot Studio aktiveres per **miljø** i Power Platform admin center:

1. Power Platform admin center → **Copilot**-fanen → **Settings**
2. Under **Copilot Studio**: velg **Entra Agent Identity for Copilot Studio**
3. Velg miljøet → **Edit setting** → slå **On** → **Save**

**Resultat:** Alle nye agenter som opprettes i Copilot Studio i det valgte miljøet, får automatisk en Entra-agentidentitet.

### Blueprint for Copilot Studio *(Verified MCP 2026-04)*

Når den første agentidentiteten opprettes i miljøet etter aktivering, legges et blueprint kalt **«Microsoft Copilot Studio agent identity blueprint»** til i tenanten. En blueprint principal opprettes — denne har privilegier til å opprette agentidentiteter og agentbrukere i tenanten.

**Blueprint ID:** `25664c89-cea5-4ab6-b924-a54fd8a19ae0` — alle Copilot Studio-agentidentiteter er barn av dette globale blueprintet. *(Verified MCP 2026-04)*

### Administrasjon og validering

Finn agentens Entra Agent ID (GUID):
- Copilot Studio → agent **Settings** → **Advanced** → **Metadata** → **Entra Agent ID**

Bruk dette GUID-et i Microsoft Entra admin center for å bekrefte og administrere identiteten.

**Viktig:** Sletter du agenten fra Copilot Studio, slettes også den tilknyttede agentidentiteten fra Entra.

**Opt-out er midlertidig:** Muligheten til å slå av Entra Agent Identity per miljø er midlertidig — Microsoft vil gjøre det obligatorisk for alle nye agenter i fremtiden. *(Verified MCP 2026-04)*

**Backfill:** Eksisterende agenter opprettet før Entra Agent Identity ble aktivert, fortsetter å bruke app registrations og vil migreres til Agent IDs i fremtiden. Governance-kapabiliteter fungerer for begge identitetstyper i overgangsperioden. *(Verified MCP 2026-04)*

### Nettverkssikkerhet for Copilot Studio-agenter

Entra Agent ID kombinert med **Global Secure Access** gir nettverksnivå-kontroller for Copilot Studio-agenter:
- Webinnholdsfiltrering
- Trusselintelligensfiltrering
- Nettverksfilfiltrering for agenttrafikk

## Norsk offentlig sektor — Alignment

### Digdir-krav

**Nasjonal identitetsinfrastruktur:**
Digdir forventer at offentlige virksomheter bruker anerkjente identitetsrammeverk. Entra Agent ID er Microsofts primære rammeverk for agentidentiteter og er bygget på den samme Entra ID-plattformen som allerede er mye brukt i norsk offentlig sektor.

**Feide og ID-porten:**
- Entra Agent ID er primært relevant for **maskin-til-maskin** og **autonom agent**-kommunikasjon — ikke direkte sluttbrukerauthentisering
- Feide/ID-porten er fortsatt det primære rammeverket for sluttbruker-autentisering i offentlig sektor
- For agenter som handler **på vegne av en bruker** (attended/delegert modus), bør brukerens opprinnelige autentisering skje via Feide/ID-porten, mens agentidentiteten håndterer downstream-tilgang til systemer

**Personopplysningsloven og GDPR:**
- Agentidentiteter logger all aktivitet — dette er positivt for revisjonskrav, men innebærer at det kan lagres informasjon om agenthandlinger som kan knyttes til enkeltpersoner
- Vurder hvilke data agenten aksesserer og om disse er personopplysninger — sett opp tilpassede databehandlingsavtaler ved behov

### NSM Grunnprinsipper

**Prinsipp 4: Identitetsstyring og tilgangskontroll**
Entra Agent ID dekker NSMs krav om identitetsstyring og tilgangskontroll direkte:
- Alle agenter har unike, sporbare identiteter
- Minste privilegium håndheves strukturelt (blokkerte høyprivilegerte roller)
- Tilgangstildeling kan gjennomgås periodisk via access reviews

**Prinsipp 5: Loggføring og overvåkning**
- Sign-in og audit logs for agenter i Entra admin center
- Integrasjon med Log Analytics og Microsoft Sentinel for SOC-synlighet
- Rapporter over risikofulle agenter via Identity Protection

### AI Act og ansvarlig AI

Entra Agent ID støtter AI Act-kravene om **menneskelig tilsyn** og **dokumentasjon**:
- Sponsorship-funksjonen sikrer at en ansvarlig person har tilsyn med agenten
- Blueprint-modellen gir klar typeklassifisering (viktig for AI Act-risikovurdering)
- Audit logs muliggjør etterprøvbarhet av agenthandlinger

### Schrems II og dataresidens

Agentidentitetsobjektene i Entra ID lagres i Microsofts tenantinfrastruktur — samme geo-restriksjoner som Entra ID ellers. For norsk offentlig sektor med krav om EØS-lagring: bekreft at tenanten er konfigurert med Norge/EU-primærregion.

## Sikkerhetshensyn og beste praksis

### Unngå vanlige feil

**Feil 1: Bruke Managed Identity der agentidentitet er riktig**

```bash
# ❌ Unngå dette for selve AI-agenten som handler autonomt
# System-assigned Managed Identity gir ikke samme
# agentspesifikke governance og lifecycle management

# ✅ Bruk Foundry/Copilot Studios innebygde agentidentitetsprovisjonering,
# eller registrer agenten eksplisitt i Entra Agent ID
```

**Feil 2: Over-privilegering av agenter**

```bash
# ❌ Gi aldri bred tilgang på abonnementsnivå
az role assignment create \
  --role "Contributor" \
  --assignee <agentIdentityId> \
  --scope /subscriptions/{sub-id}

# ✅ Gi kun nødvendig tilgang på ressursnivå
az role assignment create \
  --role "Storage Blob Data Reader" \
  --assignee <agentIdentityId> \
  --scope /subscriptions/{sub}/resourceGroups/{rg}/
          providers/Microsoft.Storage/storageAccounts/{name}
```

**Feil 3: Glemme å tildele tillatelser på nytt ved publisering**

Når en Foundry-agent publiseres, endres identiteten fra delt prosjektidentitet til distinkt agentidentitet. Alle RBAC-tildelinger må opprettes for den nye identiteten.

### Sjekkliste for implementering

**Fase 1: Synlighet (Uke 1)**
- [ ] Aktiver Entra Agent ID i tenanten (del av Microsoft Agent 365 / Frontier-program)
- [ ] Gjennomgå eksisterende agenter i Agent Registry
- [ ] Identifiser «shadow agents» — agenter uten registrert identitet
- [ ] Tildel agent-sponsorer for alle kritiske agenter

**Fase 2: Governance (Uke 2-3)**
- [ ] Konfigurer agent collections for logisk gruppering
- [ ] Sett opp Conditional Access-policyer for agentidentiteter
- [ ] Aktiver Identity Protection for agenter
- [ ] Definer lifecycle workflows for automatisert opprydding

**Fase 3: Least Privilege (Uke 3-4)**
- [ ] Gjennomgå RBAC-tildelinger for alle agentidentiteter
- [ ] Fjern over-privilegerte tildelinger
- [ ] Konfigurer Access Reviews for periodisk gjennomgang
- [ ] Verifiser at høyprivilegerte roller ikke er tildelt agenter

**Fase 4: Monitoring (Uke 4-5)**
- [ ] Konfigurer sign-in og audit logs til Log Analytics
- [ ] Sett opp Sentinel-regler for risikofulle agenthandlinger
- [ ] Definer varsling ved anomal agentaktferd
- [ ] Test revokering — blokker en testagent og verifiser umiddelbar stopp

## Status og tilgjengelighet

| Komponent | Status | Tilgang |
|-----------|--------|---------|
| **Entra Agent ID (kjerne)** | Public Preview | Microsoft Frontier-program / Agent 365 |
| **Agent Registry** | Public Preview | Microsoft Frontier-program |
| **Foundry-integrasjon** | Public Preview | Alle Foundry-brukere |
| **Copilot Studio-integrasjon** | Preview (opt-out midlertidig) | Power Platform admin center |
| **Conditional Access for agenter** | Public Preview | Microsoft Frontier-program |
| **Identity Protection for agenter (risky agents)** | Public Preview | Microsoft Frontier-program |
| **Global Secure Access for agenter** | Public Preview | Microsoft Frontier-program |
| **AI Prompt Shield (Global Secure Access)** | Nytt — Ignite 2025 | Microsoft Entra Internet Access |
| **App Service/Azure Functions agent identity** | Nytt | Azure App Service |
| **Teams Developer Portal agent blueprints** | Nytt | Teams Developer Portal |

*(Verified MCP 2026-04)*

**Merknad om Frontier-programmet:** *(Verified MCP 2026-04)* Fullstendig Entra Agent ID-funksjonalitet krever deltakelse i Microsoft Frontier-programmet og en Microsoft 365 Copilot-lisens. Frontier aktiveres via M365 admin center → Copilot → Settings → User access → Copilot Frontier. Foundry-integrert agentidentitet er tilgjengelig for alle Foundry-brukere uten Frontier.

## Kilder

1. [Security for AI agents with Microsoft Entra Agent ID](https://learn.microsoft.com/entra/agent-id/identity-professional/security-for-ai) — Oversikt over sikkerhetsrammeverket
2. [What are agent identities](https://learn.microsoft.com/entra/agent-id/identity-platform/what-is-agent-id) — Kjernekonsepted for agentidentiteter
3. [Agent identity and blueprint concepts in Microsoft Entra ID](https://learn.microsoft.com/entra/agent-id/identity-platform/key-concepts) — Blueprints og arkitektur
4. [Agent identity concepts in Microsoft Foundry](https://learn.microsoft.com/azure/ai-foundry/agents/concepts/agent-identity?view=foundry) — Foundry-integrasjon med agentidentiteter
5. [Automatically create Microsoft Entra agent identities for Copilot Studio agents](https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-use-entra-agent-identities) — Copilot Studio-integrasjon
6. [What is the Microsoft Entra Agent Registry?](https://learn.microsoft.com/entra/agent-id/identity-platform/what-is-agent-registry) — Agent Registry-konsepter
7. [Authorization in Microsoft Entra Agent ID](https://learn.microsoft.com/entra/agent-id/identity-professional/authorization-agent-id) — Roller, tillatelser og blokkerte rettigheter
8. [Governing Agent Identities (Preview)](https://learn.microsoft.com/entra/id-governance/agent-id-governance-overview) — Identity Governance for agenter
9. [Conditional Access for Agent ID (Preview)](https://learn.microsoft.com/entra/identity/conditional-access/agent-id) — Conditional Access for agentidentiteter
10. [Protect agent identities with Microsoft Entra](https://learn.microsoft.com/microsoft-agent-365/admin/capabilities-entra) — Microsoft Agent 365-integrasjon
11. [What's new at Microsoft Ignite 2025 - Microsoft Entra](https://learn.microsoft.com/entra/fundamentals/whats-new-ignite-2025) — Annonsering og ny dokumentasjon. Verified MCP 2026-04: Bekrefter 50+ nye artikler om Agent ID, nye RBAC-roller (Agent ID Administrator, Agent ID Developer, Agent Registry Administrator), Conditional Access for agentidentiteter, Identity Protection for agenter (risky agents concept), AI Prompt Shield (Entra Internet Access), og Security Copilot + Entra-integrasjoner.
12. [Surfing the AI Wave: Manage, Govern, and Protect AI Agents with Microsoft Entra Agent ID](https://techcommunity.microsoft.com/blog/microsoft-entra-blog/surfing-the-ai-wave-manage-govern-and-protect-ai-agents-with-microsoft-entra-age/2464407) — Offisiell Microsoft Entra-blogg, Ignite 2025

---

## For Cosmo

**Hvornår anbefale Entra Agent ID:**
- Kunden bygger AI-agenter med Azure AI Foundry eller Copilot Studio → Entra Agent ID er innebygd, aktiver det
- Kunden har mange agenter og mangler oversikt («vi vet ikke hvor mange agenter vi har») → Agent Registry løser dette
- Kunden er i offentlig sektor med revisjonskrav → Agentspesifikk audit logging er nøkkelargumentet
- Kunden bekymrer seg for kompromitterte agenter → Identity Protection + Conditional Access gir automatisert respons

**Spørsmål å stille kunden:**
- «Vet dere hvor mange AI-agenter dere har i dag — inkludert de som er bygget av sluttbrukere i Copilot Studio?»
- «Har dere noen som er ansvarlig (sponsor) for hvert sett med agenter i produksjon?»
- «Bruker agentene hardkodede API-nøkler, eller har de dedikerte identiteter?»
- «Kan dere umiddelbart blokkere en kompromittert agent — eller vil den fortsette å kjøre?»
- «Har dere revisjonsspor for hva hver enkelt agent har gjort og aksessert?»

**Trigger-spørsmål:**
- «Hvordan sikrer vi AI-agentene våre?»
- «Hva gjør vi med agent sprawl?»
- «Kan en kompromittert agent ta over andre systemer?»
- «Hvordan oppfyller vi AI Act-kravene om menneskelig tilsyn av agenter?»
- «Hva er forskjellen mellom Managed Identity og agentidentitet for AI-agenter?»

**Viktige avklaringer:**
- Entra Agent ID er i **Public Preview** — ikke GA. For produksjonsscenarioer i offentlig sektor: vurder modenhetsnivå og preview-vilkår nøye
- Krever **Microsoft Frontier-program** for full funksjonalitet — Foundry-integrasjon er bredere tilgjengelig
- **Copilot Studio-integrasjonen** aktiveres per miljø og er i preview — ny funksjonalitet vil komme
- Agentidentiteter er **ikke** en erstatning for Managed Identity for infrastruktur-til-tjeneste-kommunikasjon — de er komplementære