499 lines
31 KiB
Markdown
499 lines
31 KiB
Markdown
# Microsoft Entra Agent ID — Zero Trust for AI-agentidentiteter
|
|
|
|
**Category:** AI Security Engineering
|
|
**Last updated:** 2026-06-19
|
|
**Status:** Public Preview (utvidet etter Ignite 2025; se §Ignite 2025-utvidelser)
|
|
**Målgruppe:** Arkitekter som skal sikre AI-agenter med dedikerte identiteter og Zero Trust-prinsipper
|
|
**Type:** reference
|
|
**Source:** https://learn.microsoft.com/entra/id-governance/agent-id-governance-overview
|
|
|
|
### Ignite 2025-utvidelser (Verified MCP 2026-05)
|
|
|
|
Microsoft har bredt utvidet Entra Agent ID-porteføljen i forbindelse med Ignite 2025. Nye/oppdaterte kapabiliteter relevante for arkitekter:
|
|
|
|
- **Conditional Access for agenter:** Egne policymaler — inkludert "Block high-risk agent identities" — som utvider Zero Trust til AI-agenter. Brukes på samme policymotor som menneske-/workload-identiteter.
|
|
- **Identity Protection for agenter:** Nytt "Risky agents"-konsept og "Identity risk management agent" med dedikert risikorapportering for AI-agenter.
|
|
- **Agent ID-roller:** Tre nye RBAC-roller — *Agent ID Administrator*, *Agent ID Developer*, *Agent Registry Administrator* — for granulær delegasjon av agent-administrasjon.
|
|
- **Microsoft Agent Identity Platform:** Utviklerflater for OAuth-flyter (autonomous app, on-behalf-of, agent user), token-claims, blueprints og agent-metadata/discoverability.
|
|
- **Security Copilot + Entra:** Oppdaterte scenarioer (Entra agents, Conditional Access-optimalisering, lifecycle workflows, governance-optimering) som integrerer agent-identitet med AI-assistert sikkerhetsadministrasjon.
|
|
|
|
**Copilot Studio-integrasjon (preview):** Når funksjonen aktiveres på miljønivå i Power Platform Admin Center, oppretter Copilot Studio automatisk en Entra Agent ID for hver ny agent og knytter den til *Microsoft Copilot Studio agent identity blueprint* (Blueprint ID `25664c89-cea5-4ab6-b924-a54fd8a19ae0`). Eksisterende agenter beholder sine app registrations til de migreres senere — governance fungerer for begge under overgangen.
|
|
|
|
## Innhold
|
|
|
|
- [Introduksjon](#introduksjon)
|
|
- [Hva er Microsoft Entra Agent ID?](#hva-er-microsoft-entra-agent-id)
|
|
- [Kjernekomponenter og begreper](#kjernekomponenter-og-begreper)
|
|
- [Zero Trust-prinsipper for agenter](#zero-trust-prinsipper-for-agenter)
|
|
- [Agent Registry — Livsløpsadministrasjon](#agent-registry--livsløpsadministrasjon)
|
|
- [Workload Identities vs. Agentidentiteter](#workload-identities-vs-agentidentiteter)
|
|
- [Integrasjon med Microsoft Foundry](#integrasjon-med-microsoft-foundry)
|
|
- [Integrasjon med Copilot Studio](#integrasjon-med-copilot-studio)
|
|
- [Norsk offentlig sektor — Alignment](#norsk-offentlig-sektor--alignment)
|
|
- [Sikkerhetshensyn og beste praksis](#sikkerhetshensyn-og-beste-praksis)
|
|
- [Status og tilgjengelighet](#status-og-tilgjengelighet)
|
|
- [Kilder](#kilder)
|
|
- [For Cosmo](#for-cosmo)
|
|
|
|
## 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-06)*
|
|
|
|
**Lisenskrav:** Conditional Access for agenter krever **Microsoft Entra ID P1 eller P2** og en **Microsoft Agent 365-lisens per bruker** (lisenshåndhevelse kommer snart). Nettverkskontroller for agenter krever **Microsoft Entra Internet Access**. *(Verified MCP 2026-06)*
|
|
|
|
**Scoping etter tilgangsmønster (subjekt vs. audience):** Entra utsteder et token til ett subjekt for én audience (ressurs), og CA evalueres på begge. Hvilket objekt policyen treffer avhenger av flyt:
|
|
- **On-behalf-of (delegert):** Brukeren er subjektet → CA target **users and groups** (ikke agentidentiteten). Token-veksling til nedstrøms ressurs evalueres også.
|
|
- **App-only (autonom):** Agentidentiteten er subjektet → CA scopes til **agentidentiteten**.
|
|
- **Agent-som-bruker (agent's user account):** Agentens brukerkonto er subjektet → policy evalueres mot **brukerkontoen**, ikke agentidentiteten.
|
|
|
|
**Scoping-muligheter:** Policyer kan scopes til: alle agentidentiteter i tenanten; spesifikke agentidentiteter (object ID); agentidentiteter basert på custom security attributes; agentidentiteter gruppert etter blueprint (dekker alle nåværende og fremtidige instanser av blueprintet, men IKKE agent users); alle agent users.
|
|
|
|
**Conditions:** Agent risk (high/medium/low) fra Identity Protection er tilgjengelig som condition. For agenter som kjører på managed endpoints (f.eks. **Windows 365 Cloud PCs for Agents**) kan **«Agent execution environments» (Preview)**-condition scope policyer til device-compliance og compliant-network-kontroller. *(Verified MCP 2026-06)*
|
|
|
|
**Viktig — CA-grenser:** CA gjelder IKKE for: agent identity blueprint → Graph-kall (oppretting av agentidentitet/agent user); intermediary token exchange på `AAD Token Exchange Endpoint: Public` (Resource ID `fb60f99c-7a34-4190-8149-302f77469936`); når Security defaults er aktivert; eller når en agent bruker API-nøkkel (bypasser Entra-token-pipeline helt). CA gjelder for agent identity → resource og agent user → resource flows. *(Verified MCP 2026-06)*
|
|
|
|
### 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. Microsoft 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 Microsoft Foundry
|
|
|
|
Microsoft 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**
|
|
|
|
**Forutsetning:** Du må være Power Platform **tenant admin** eller ha **Environment Admin**-rollen for å konfigurere dette per miljø. *(Verified MCP 2026-06)*
|
|
|
|
**Resultat:** Alle nye agenter som opprettes i Copilot Studio i det valgte miljøet, får automatisk en Entra-agentidentitet.
|
|
|
|
**Connector-tillatelser som API-permissions:** Når en maker publiserer en agent, fester Copilot Studio API-permissions på agentens Entra Agent ID for hver Power Platform-connector agenten bruker. Dette gjør at Entra- og Microsoft 365-admins kan se hvilke connectorer en agent kan kalle uten å åpne Power Platform admin center. Scopene håndheves kun av Power Platform-connector-runtime og re-valideres mot Advanced Connector Policies (ACP) og DLP — de kan ikke brukes til å omgå governance-policyer. Fordi scopene er førsteklasses API-permissions, kan admins **target dem med Conditional Access** (nettverkslokasjon, device-compliance, risikobaserte conditions før tokens utstedes for en bestemt connector-ressurs). *(Verified MCP 2026-06)*
|
|
|
|
### Blueprint for Copilot Studio *(Verified MCP 2026-06)*
|
|
|
|
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-06)*
|
|
|
|
### 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-06)*
|
|
|
|
**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-06)*
|
|
|
|
### 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 | Entra ID P1/P2 + Agent 365-lisens per bruker (nettverkskontroller: Entra Internet Access) |
|
|
| **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-06 for Conditional Access- og Copilot Studio-rader; øvrige rader fra Ignite 2025-dokumentasjon)*
|
|
|
|
**Merknad om Frontier-programmet:** *(Verified MCP 2026-06)* 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.
|
|
|
|
**Lisensering av Conditional Access for agenter (spesifikt):** *(Verified MCP 2026-06)* Conditional Access for agenter krever **Microsoft Entra ID P1/P2** og en **Microsoft Agent 365-lisens per bruker** (håndhevelse kommer snart). Nettverkskontroller for agenter krever **Microsoft Entra Internet Access**.
|
|
|
|
## 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/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 Microsoft 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
|