ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-security/references/ai-security-engineering/entra-agent-id-zero-trust.md

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:

# 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

# 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

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

# ❌ 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 — Oversikt over sikkerhetsrammeverket
2. What are agent identities — Kjernekonsepted for agentidentiteter
3. Agent identity and blueprint concepts in Microsoft Entra ID — Blueprints og arkitektur
4. Agent identity concepts in Microsoft Foundry — Foundry-integrasjon med agentidentiteter
5. Automatically create Microsoft Entra agent identities for Copilot Studio agents — Copilot Studio-integrasjon
6. What is the Microsoft Entra Agent Registry? — Agent Registry-konsepter
7. Authorization in Microsoft Entra Agent ID — Roller, tillatelser og blokkerte rettigheter
8. Governing Agent Identities (Preview) — Identity Governance for agenter
9. Conditional Access for Agent ID (Preview) — Conditional Access for agentidentiteter
10. Protect agent identities with Microsoft Entra — Microsoft Agent 365-integrasjon
11. What's new at Microsoft Ignite 2025 - Microsoft Entra — 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 — 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