feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command

Add /ultraresearch-local for structured research combining local codebase analysis with external knowledge via parallel agent swarms. Produces research briefs with triangulation, confidence ratings, and source quality assessment. New command: /ultraresearch-local with modes --quick, --local, --external, --fg. New agents: research-orchestrator (opus), docs-researcher, community-researcher, security-researcher, contrarian-researcher, gemini-bridge (all sonnet). New template: research-brief-template.md. Integration: --research flag in /ultraplan-local accepts pre-built research briefs (up to 3), enriches the interview and exploration phases. Planning orchestrator cross-references brief findings during synthesis. Design principle: Context Engineering — right information to right agent at right time. Research briefs are structured artifacts in the pipeline: ultraresearch → brief → ultraplan --research → plan → ultraexecute. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-08 08:58:35 +02:00 · 2026-04-08 08:58:35 +02:00 · baa2d0220b
commit baa2d0220b
488 changed files with 213221 additions and 0 deletions
--- a/skills/ms-ai-security/references/ai-security-engineering/entra-agent-id-zero-trust.md
+++ b/skills/ms-ai-security/references/ai-security-engineering/entra-agent-id-zero-trust.md
@ -0,0 +1,438 @@
+# Microsoft Entra Agent ID — Zero Trust for AI-agentidentiteter
+
+**Kategori:** AI Security Engineering
+**Sist oppdatert:** 2026-02
+**Status:** Public Preview (annonsert Ignite november 2025, utvidet preview fra mai 2025)
+**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.
+
+### 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
+- **Access reviews:** Regelmessig gjennomgang av agenttilganger — over-privilegerte agenter identifiseres
+- **Lifecycle workflows:** Automatisert opprydding — f.eks. fjern tilgang etter prosjektslutt
+- **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
+
+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.
+
+### 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.
+
+### 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 | Power Platform admin center |
+| **Conditional Access for agenter** | Public Preview | Microsoft Frontier-program |
+| **Identity Protection for agenter** | Public Preview | Microsoft Frontier-program |
+| **Global Secure Access for agenter** | Public Preview | Microsoft Frontier-program |
+
+**Merknad om Frontier-programmet:** Fullstendig Entra Agent ID-funksjonalitet krever deltakelse i Microsoft Frontier-programmet (tidlig tilgang til AI-innovasjoner). 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
+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