Microsoft AI Agents — Anatomie einer neuen Identitätsklasse - Teil I
“In deinem Microsoft Tenant gibt es nicht 1 Agent. Sondern hunderte Agents. Und Du weißt es noch nicht.”
Das ist der Horror den Identity Admins in Entra ID momentan tagtäglich erleben müssen. Die Welt der AI Agents wächst unaufhaltsam und in den meisten Microsoft Tenants fehlen momentan sowohl die organisatorischen Maßnahmen für den sicheren Umgang mit AI und AI Agents als auch die technischen Guardrails um ein sicheres Arbeiten mit AI Agents gewährleisten zu können.
Und genau deswegen starten wir mit diesem Artikel in eine 3-teilige Blogserie zum Thema “Microsoft AI Agents”:
- Teil I: Welche Arten von Agents gibt es im Microsoft Ökosystem? Wie authentifizieren sich diese Agents? Wie sieht das Berechtigungskonzept aus? Welche Risiken bergen diese Agents?
- Teil II: Wie schaffen wir Visibility und haben einen guten Überblick über die momentan verwendeten Agents? Wie sichern wir zukünftig erstellte Agents von Beginn an sicher ab?
- Teil III: Wie können wir momentan technisch die Funktionalitäten von Agents begrenzen, sodass wir sie mit gutem Gewissen an Enduser für ihr Daily Work freigeben können?
Dieser Artikel bricht das Microsoft AI Agent Ökosystem aus der Perspektive eines Identity Administrator bis ins Detail herunter - ohne Marketing Bla Bla.
1. Was ist ein Agent — und was nicht
Bevor wir in die Taxonomie gehen: Eine Begriffsklärung, die für Identity Admins entscheidend ist.
Ein Agent ist keine Erweiterung eines Benutzers (zumindest meistens…). Er ist eine eigene Identität — mit eigenen Credentials, eigenen Berechtigungen, eigenem Token-Lebenszyklus und eigenem Risikoprofil.
| Konzept | Erklärung |
|---|---|
| Chatbot / Bot | Regelbasierte Konversationslogik. Kein LLM, keine autonomen Entscheidungen. |
| Copilot Feature | UI-Erweiterung auf Basis von Microsoft 365 Copilot. Operiert als User-Identität. |
| AI Agent | Autonome Einheit mit eigenem Identity-Principal, eigenem Token, eigenem Aktionsumfang. Kann mit anderen Agents kommunizieren, Daten lesen/schreiben, Aktionen ausführen — ohne direkte Benutzerinteraktion. |
Ein Agent, der im Hintergrund SharePoint-Dateien liest, E-Mails sendet und externe APIs aufruft, ist aus Entra-Perspektive nicht von einem Service Account zu unterscheiden — außer dass er sich autonom entscheidet, welche dieser Aktionen er wann ausführt.
2. Taxonomie: (fast) alle Agent-Formen im Microsoft Ökosystem
Das Microsoft AI Ökosystem 2025/2026 ist fragmentiert. Agents entstehen an verschiedensten Orten & Plattformen — mit unterschiedlichen Identity-Mechanismen, unterschiedlichen Governance-Modellen und unterschiedlichen Security-Profilen.
Declarative Agents (M365 Copilot)
Konfigurationsbasierte Agents, die als JSON-Manifest definiert werden. Sie laufen auf dem Copilot-eigenen Orchestrator und LLM — Microsoft hostet die gesamte Infrastruktur.
Capabilities: SharePoint Knowledge, Code Interpreter, M365 Copilot Connectors, API Plugins, Connected Agents — seit GA auch Orchestrierung mehrerer Declarative Agents
Beispiel: Microsofts eigener “Researcher” Agent
Identity: Blueprint + Agent Identity. Der Agent operiert unter einer vom Blueprint abgeleiteten Agent Identity Service Principal oder bei direkter Nutzung durch einen User: OBO-Flow (OBO = “on-behalf of”), d.h. der Agent agiert im Scope des angemeldeten Benutzers.
Sehr einfach zu erstellen — jeder M365-Copilot Nutzer mit entsprechender Lizenz kann einen Declarative Agent bauen und im Unternehmen teilen. Das ist einer der primären Vektoren für “Shadow” Agents.
Custom Engine Agents (M365 Agent Store)
Full-Stack Agents mit eigenem Orchestrator, eigener LLM-Wahl und eigenem API-Stack. Publiziert über den M365 Agent Store. Werden dort eingesetzt, wo die Logik von Declarative Agents nicht ausreicht.
Identity: Eigener Service Principal. Kein Blueprint-Mechanismus — die App Registration in Entra ID ist die primäre Governance-Einheit.
Security-Relevanz: Höchste Flexibilität = höchste Angriffsfläche. Permissions sind manuell konfiguriert, kein automatisches Inheritance-Modell.
Copilot Studio Agents (Power Platform)
Low-Code / No-Code Agent Builder auf der Power Platform.
Identity — zwei Modi:
- Legacy: Klassische App Registration (Service Principal) in Entra ID. Standard für alle Agents, die vor Entra Agent Identity Enablement im Environment erstellt wurden.
- Entra Agent Identity (Preview → Mandatory): Agents erhalten automatisch einen Service Principal mit Subtype “Agent”. Derzeit Opt-in per Power Platform Environment, aber Microsoft hat den Übergang zu Mandatory angekündigt.
Copilot Studio ist der zugänglichste Agent Builder für User mit M365 Copilot Lizenz und hat in Kombination mit der hohen Vielfalt an Möglichkeiten zur Agent Entwicklung / Erstellung das vermutlich höchste Gefahrenpotential.
Azure AI Foundry Agents
Die technisch tiefste Implementierung. Foundry stellt die gesamte Agent-Infrastruktur für Enterprise-AI-Szenarien bereit. Microsoft Foundry provisioniert und managed Agent Identities automatisch über den Entra Agent ID Lifecycle.
Identity: Blueprint + Managed Identity (empfohlen).
Security-Relevanz: Direkte Integration mit Azure RBAC, Key Vault, Storage, und allen Azure Resource Providern. Der Token-Exchange-Chain ist hier am komplexesten — und damit am fehleranfälligsten.
Agent User Accounts
Eine oft übersehene Variante: Agents können als reguläre Entra-User-Accounts konfiguriert werden — mit Mailbox, Kalender, Gruppenmitgliedschaften und M365-Lizenzen. Diese “Digital Workers” agieren als vollwertige Benutzeridentitäten.
Identity: Standard Entra User Account, verknüpft mit einem Agent. CA-Policies greifen wie bei normalen Benutzern.
Ein Agent User Account hat alle Berechtigungen eines normalen Benutzers plus potenziell automatisierten Zugriff rund um die Uhr. Wenn der Account kompromittiert wird — oder der Agent fehlerhaft implementiert ist — ist die Auswirkung identisch mit einem kompromittierten Benutzeraccount.
3. Microsoft Entra Agent ID Platform — Die neue Identitätsschicht
Im März 2026 hat Microsoft die Entra Agent ID Platform als GA veröffentlicht. Das ist keine Evolution bestehender Konzepte — es ist eine neue Identitätskategorie mit mehreren neuen Entra-Objekttypen.
Die neuen Objekttypen
Agent Identity Blueprint: Das Template für eine “Klasse” von Agents. Hält die OAuth Credentials, Permission Declarations (RequiredResourceAccess), Authentication Settings (OptionalClaims), Custom Security Attributes und Governance Controls (InheritablePermissions). Ein Blueprint kann unternehmensweit oder multi-tenant deployed werden.
Blueprint Principal: Das Entra-Objekt, das entsteht, wenn ein Blueprint einem Tenant hinzugefügt wird. Dieser Principal ist der Actor in Entra Audit Logs, wenn Agents erstellt oder modifiziert werden — der oid-Claim im Token referenziert diesen Principal, nicht die einzelne Agent Identity.
Agent Identity: Eine Service Principal Instanz mit Subtype “Agent”. Repräsentiert einen spezifischen Agent zur Laufzeit. Kritisch: Agent Identities können sich nicht selbst authentifizieren — sie sind auf die OAuth Credentials des Blueprints angewiesen, um Tokens zu erhalten. D.h. ein Löschen des Blueprints hat Folgen auf die Authentifizierung der daraus abgeleiteten Agent Identities!
Agent User Account: Ein reguläres Entra User Account, das mit einem Agent verknüpft ist. (kein neuer Objekttyp - Standard Member Account)
Credentials auf Blueprints
| Credential Typ | Mechanismus | Empfehlung |
|---|---|---|
| Client Secret | Shared secret string | Nicht empfohlen / unsicher — manuelles Secret-Lifecycle-Management |
| Certificate | X.509 Assertion | Besser, aber auch hier Secret-Lifecycle-Management erforderlich |
| Federated Credential (Managed Identity) | Workload Identity Federation | Empfohlen — keine gespeicherten Secrets, Azure rotiert automatisch |
Das Federated Credential Modell ist aus Security-Perspektive die einzig akzeptable Wahl für Produktiv-Deployments. Die Managed Identity authentifiziert das Blueprint bei Entra ID — der Blueprint erbt keine Berechtigungen auf Ziel-Ressourcen, das macht die Agent Identity selbst via RBAC.
Die gefährlichste Permission: AgentIdentity.CreateAsManager
Diese Microsoft Graph Permission ermöglicht es einem Blueprint, selbständig Agent Identities via Graph API zu provisionieren. Ein Blueprint mit dieser Permission kann neue Service Principals mit Subtype “Agent” erstellen, diese mit Permissions ausstatten und den vollständigen Agent Identity Lifecycle managen.
Wer einen Blueprint kontrolliert, kontrolliert alle Agent Identities, die daraus entstehen. Der Blueprint ist damit ein High-Value Target für Angreifer — kompromittiert man den Blueprint, kompromittiert man die gesamte Agent-Klasse. Blueprints sollten wie Privileged App Registrations behandelt werden: PIM-ähnliche Governance, minimale Zugriffsberechtigung, regelmäßige Access Reviews.
InheritDelegatedPermissions — Permission Creep by Design
Wenn InheritDelegatedPermissions auf einem Blueprint aktiviert ist, erben alle Agent Identities dieses Blueprints automatisch alle delegierten Permissions, die ein Admin für den Blueprint Principal consented hat.
Szenario: Ein Admin consented dem Blueprint Principal Mail.ReadWrite und Files.ReadWrite.All - weil ein einzelner Use Case beides benötigt. Mit InheritDelegatedPermissions erhalten jetzt alle Agent Identities dieses Blueprints diese Permissions — auch diejenigen, die nur Kalenderdaten benötigen.
4. Token Flows — Das technische Herzstück
Die kritischste Frage für jeden Identity Admin: Unter wessen Identität operiert der Agent, wenn er auf Ressourcen zugreift? Die Antwort hängt vollständig vom Token Flow ab — und davon, wer das Ziel einer Conditional Access Policy ist.
Attended / OBO Flow (on-behalf-of)
Einsatzgebiet: Agent operiert im Kontext eines angemeldeten Benutzers. Der Benutzer interagiert aktiv mit dem Agent.
Der Agent kann nicht mehr als der Benutzer. Das klingt sicher — ist es aber nur, wenn das Least-Privilege-Prinzip für den Benutzer gilt. In der Praxis haben viele Benutzer weit mehr Berechtigungen als für ihren Job notwendig. Ein Agent im OBO-Flow erbt diesen gesamten Overprivilege-Scope.
Im OBO Flow erbt der Agent alle Permissions des Benutzers — nicht nur die, die der Agent selbst deklariert hat. Wenn ein Agent Mail.Read als delegierte Permission deklariert, der authentifizierte Benutzer aber zusätzlich Files.ReadWrite.All und Teams.ReadWrite.All besitzt, kann ein kompromittierter Agent-Token diese erweiterten Scopes potenziell nutzen. Clean-Up von User-Overprivilege ist damit im Kontext von AI Agents keine Governance-Empfehlung mehr, sondern eine Notwendigkeit.
Unattended / Application-Only Flow (Client Credentials)
Einsatzgebiet: Agent operiert ohne angemeldeten Benutzer — autonome Hintergrundprozesse, Batch-Operationen, scheduled Tasks.
Kein User-Kontext bedeutet kein natürliches Berechtigungslimit. Application Permissions mit dem Suffix .All wirken tenant-weit — ein Agent mit Mail.ReadWrite.All kann auf die Mailboxen aller Benutzer im Tenant zugreifen, ohne dass sich je ein Benutzer angemeldet hat. Jede .All-Permission ist ein potenzielles Datenleck. Für die Auswertung gibt es ein von mir publiziertes Tool namens “Consentra” über welches Du auch auf dieser Webseite direkt einen HTML Report zur Auswertung dieser Permissions erhältst.
5. Graph API Permissions: Delegated vs. Application
Microsoft Graph ist die primäre API, über die Agents auf M365-Daten zugreifen. Das Berechtigungsmodell ist der kritischste Faktor für das Risikoprofil eines Agents.
| Typ | Beschreibung | Risikoprofil |
|---|---|---|
| Delegated Permissions | Agent agiert im Scope des angemeldeten Users. User.Read liest Profil des angemeldeten Users. | Limitiert durch User-Kontext. Sicherer, aber User-Overprivilege propagiert. |
| Application Permissions | Agent agiert ohne User-Kontext. Mail.ReadWrite.All liest/schreibt Mailboxen aller User im Tenant. | Tenant-weit wirkend. Höchstes Risikoprofil. Kein natürliches Limit. |
Resource-Specific Consent (RSC) beschränkt Graph Permissions auf spezifische Teams oder SharePoint Sites statt tenant-weit zu wirken. Statt Files.ReadWrite.All → Files.ReadWrite auf einer spezifischen SharePoint Site. Verfügbar für Teams- und SharePoint-spezifische Szenarien — sollte überall dort eingesetzt werden, wo RSC unterstützt wird.
6. Security Threat Landscape — Real CVEs, Real Techniques
Die folgende Zusammenfassung zeigt: AI Agent Security ist kein theoretisches Problem.
CVE-2025-32711 “EchoLeak” — Zero-Click Data Exfiltration (CVSS 9.3, Critical)
Entdeckt: Aim Security, Juni 2025. Gepatcht: Server-seitig durch Microsoft, kein Client Action erforderlich.
EchoLeak erfordert kein Öffnen von Attachments, kein Klicken auf Links. Die E-Mail reicht. Klassische Perimeter-Security, Endpoint-AV und Firewalls sind bei diesem Angriffstyp vollständig wirkungslos — der Exploit läuft im natürlichen Sprachraum ab, nicht im Netzwerk.
CoPhish — OAuth Token Theft via Copilot Studio (Datadog Security Labs, Oktober 2025)
Kein CVE zum Zeitpunkt der Disclosure. Die Technik ist trivial reproduzierbar und nutzt ausschließlich legitime Microsoft-Infrastruktur.
Die Domain copilotstudio.microsoft.com ist absolut legitim — kein Phishing-Indikator, keine Browser-Warnung. Der OAuth Consent Screen sieht identisch zu einem legitimen Flow aus. High-Value Target sind Application Administrators, da diese delegierten Permissions ohne weitere Einschränkungen konsenten können.
Detection: z.B. via Entra Audit Logs → Consent to application. Copilot Studio Audit → PowerPlatform workload, Operation: BotComponentUpdate, PropertyCollection enthält vermutlich *.topic.Signin.
HTTP Connector Tenant Isolation Bypass (Zenity Research, 2025)
Power Platform’s HTTP Connector umgeht Tenant Isolation Policies by design. Die Plattform validiert tenant-fremde Identitäten zur Laufzeit nicht dynamisch — sie verlässt sich auf statische Bearer Token Werte.
Ein Flow oder Agent, der ein Token aus einem externen Microsoft Tenant enthält, kann cross-tenant auf Daten zugreifen — auch wenn Tenant Isolation aktiv ist. Damit eine Cross-Tenant Data Exfiltration ohne einfache Detection-Möglichkeit.
7. Das richtige Identity-Mindset zum Thema “AI Agents”
Wer AI Agents in Microsoft Ökosystemen managed, muss sein Threat Model erweitern:
1. Jeder Agent ist eine Identität — nicht nur ein “neues” Feature
Ein Copilot Studio Agent, der E-Mails lesen kann, ist ein Service Principal mit Mail.ReadWrite Permission. Er unterliegt denselben Governance-Anforderungen wie jede andere Non-Human Identity — mit dem Unterschied, dass sie autonom entscheidet, wann und wie sie diese Permission nutzt.
2. Der Agent erbt deinen Security-Debt. Schlechte Access Hygiene bei Benutzern → Over-privileged OBO Flows. Fehlende MFA-Policies → Agents können sich oft “by-design” als Benutzer ausgeben.
3. Shadow Agents sind das neue Shadow IT. Jeder M365-Nutzer mit Copilot Studio Zugang kann einen Agent erstellen, Unternehmens-APIs verbinden und ihn im gesamten Tenant verfügbar machen — ohne IT-Involvement. Die Anzahl der Agents in einem Enterprise-Tenant wächst schneller als die Sichtbarkeit darüber. Der erste Schritt in jeder Agent Security Initiative ist: Inventarisierung.
Ausblick: Teil 2
Und damit sind wir auch schon am Ende des “Teil I” angekommen - im nächsten Teil dieser Serie gehen wir von der Anatomie zur Sichtbarkeit: Wie inventarisiert man alle Agents in einem Tenant? Welche Logging-Quellen liefern welche Signale? Was kosten die nötigen Lizenzen wirklich? Und wie lässt sich ein kontinuierlicher Agent Monitoring Workflow aufbauen.
Referenzen
- Microsoft Entra Agent ID Platform — Agent Identity Blueprints
- Entra Agent ID — Agent Identity Service Principals
- Azure AI Foundry — Agent Identity Concepts
- Azure AI Foundry — Agent-to-Agent Authentication
- Copilot Studio — Entra Agent Identities
- Microsoft Graph — Declarative Agent Architecture
- Microsoft Security Blog — Top 10 Copilot Studio Agent Security Risks
- Microsoft Security Blog — Prompts Become Shells: RCE in AI Agent Frameworks
- EchoLeak — CVE-2025-32711 Research Paper
- Datadog Security Labs — CoPhish
- Zenity Research — HTTP Connector Tenant Isolation Bypass
- Microsoft Graph Best Practices — Permissions
- Microsoft Agent Framework (GitHub)
“Your Microsoft tenant doesn’t have 1 agent. It has hundreds of agents. And you don’t know it yet.”
This is the reality Identity Admins in Entra ID are facing every single day. The world of AI agents is growing relentlessly, and most Microsoft tenants currently lack both the organizational measures for safe AI agent usage and the technical guardrails to ensure agents operate securely.
That’s exactly why we’re starting this 3-part blog series on “Microsoft AI Agents”:
- Part I: What types of agents exist in the Microsoft ecosystem? How do they authenticate? What does the permission model look like? What risks do they carry?
- Part II: How do we create visibility and maintain an overview of agents in use? How do we secure newly created agents from day one?
- Part III: What technical controls can we apply to agents today so we can confidently roll them out to end users?
This article breaks down the Microsoft AI agent ecosystem from an Identity Administrator’s perspective — no marketing fluff.
1. What is an agent — and what isn’t
Before diving into the taxonomy: a clarification that matters for Identity Admins.
An agent is not an extension of a user (at least, not always). It is its own identity — with its own credentials, its own permissions, its own token lifecycle, and its own risk profile.
| Concept | Explanation |
|---|---|
| Chatbot / Bot | Rule-based conversational logic. No LLM, no autonomous decisions. |
| Copilot Feature | UI extension on top of Microsoft 365 Copilot. Operates under the user’s identity. |
| AI Agent | Autonomous unit with its own identity principal, token, and action scope. Can communicate with other agents, read/write data, execute actions — without direct user interaction. |
An agent reading SharePoint files in the background, sending emails, and calling external APIs is indistinguishable from a service account from Entra’s perspective — except that it autonomously decides which of those actions to perform and when.
2. Taxonomy: (almost) all agent forms in the Microsoft ecosystem
The Microsoft AI ecosystem in 2025/2026 is fragmented. Agents emerge across a wide range of platforms — with different identity mechanisms, different governance models, and different security profiles.
Declarative Agents (M365 Copilot)
Configuration-driven agents defined as a JSON manifest. They run on Copilot’s own orchestrator and LLM — Microsoft hosts the entire infrastructure.
Capabilities: SharePoint Knowledge, Code Interpreter, M365 Copilot Connectors, API Plugins, Connected Agents — including orchestration of multiple Declarative Agents since GA.
Example: Microsoft’s own “Researcher” agent.
Identity: Blueprint + Agent Identity. The agent operates under an Agent Identity Service Principal derived from the blueprint, or — when used directly by a user — via OBO flow, meaning the agent acts within the scope of the signed-in user.
Extremely easy to create — any M365 Copilot user with the appropriate license can build a Declarative Agent and share it across the organization. This is one of the primary vectors for shadow agents.
Custom Engine Agents (M365 Agent Store)
Full-stack agents with their own orchestrator, LLM choice, and API stack. Published via the M365 Agent Store. Used where Declarative Agent logic falls short — complex workflow orchestration, multi-LLM routing, stateful processes.
Identity: Own service principal. No blueprint mechanism — the App Registration in Entra ID is the primary governance unit.
Security relevance: Maximum flexibility = maximum attack surface. Permissions are configured manually, no automatic inheritance model.
Copilot Studio Agents (Power Platform)
Low-code / no-code agent builder on the Power Platform.
Identity — two modes:
- Legacy: Classic App Registration (Service Principal) in Entra ID. Default for all agents created before Entra Agent Identity was enabled in the environment.
- Entra Agent Identity (Preview → Mandatory): Agents automatically receive a Service Principal with subtype “Agent”. Currently opt-in per Power Platform environment, but Microsoft has announced the transition to mandatory.
Copilot Studio is the most accessible agent builder for users with an M365 Copilot license. Combined with the wide variety of agent creation capabilities, it carries arguably the highest risk potential.
Azure AI Foundry Agents
The technically deepest implementation. Foundry provides the entire agent infrastructure for enterprise AI scenarios. Microsoft Foundry automatically provisions and manages Agent Identities throughout the Entra Agent ID lifecycle.
Identity: Blueprint + Managed Identity (recommended).
Security relevance: Direct integration with Azure RBAC, Key Vault, Storage, and all Azure Resource Providers. The token exchange chain here is the most complex — and therefore the most error-prone.
Agent User Accounts
An often-overlooked variant: agents can be configured as regular Entra user accounts — with mailbox, calendar, group memberships, and M365 licenses. These “Digital Workers” act as full user identities.
Identity: Standard Entra user account linked to an agent. CA policies apply as with regular users.
An Agent User Account has all permissions of a normal user plus potentially automated access around the clock. If the account is compromised — or the agent is poorly implemented — the impact is identical to a compromised user account.
3. Microsoft Entra Agent ID Platform — The new identity layer
In March 2026, Microsoft released the Entra Agent ID Platform as GA. This is not an evolution of existing concepts — it is a new identity category with several new Entra object types.
The new object types
Agent Identity Blueprint: The template for a “class” of agents. Holds the OAuth credentials, permission declarations (RequiredResourceAccess), authentication settings (OptionalClaims), Custom Security Attributes, and governance controls (InheritablePermissions). A blueprint can be deployed tenant-wide or multi-tenant.
Blueprint Principal: The Entra object created when a blueprint is added to a tenant. This principal is the actor in Entra Audit Logs when agents are created or modified — the oid claim in the token references this principal, not the individual Agent Identity.
Agent Identity: A Service Principal instance with subtype “Agent”. Represents a specific agent at runtime. Critical: Agent Identities cannot authenticate themselves — they rely on the blueprint’s OAuth credentials to obtain tokens. This means deleting the blueprint directly impacts authentication for all derived Agent Identities.
Agent User Account: A regular Entra user account linked to an agent. (Not a new object type — standard member account.)
Credentials on blueprints
| Credential Type | Mechanism | Recommendation |
|---|---|---|
| Client Secret | Shared secret string | Not recommended — manual secret lifecycle management |
| Certificate | X.509 Assertion | Better, but still requires lifecycle management |
| Federated Credential (Managed Identity) | Workload Identity Federation | Recommended — no stored secrets, Azure rotates automatically |
The Federated Credential model is the only acceptable choice for production deployments from a security perspective. The Managed Identity authenticates the blueprint to Entra ID — the blueprint does not inherit permissions on target resources; that is handled by the Agent Identity itself via RBAC.
The most dangerous permission: AgentIdentity.CreateAsManager
This Microsoft Graph permission allows a blueprint to autonomously provision Agent Identities via the Graph API. A blueprint with this permission can create new Service Principals with subtype “Agent”, assign them permissions, and manage the full Agent Identity lifecycle.
Whoever controls a blueprint controls all Agent Identities derived from it. The blueprint is therefore a high-value target for attackers — compromise the blueprint, compromise the entire agent class in one move. Blueprints should be treated like Privileged App Registrations: PIM-like governance, minimal access rights, regular access reviews.
InheritDelegatedPermissions — Permission Creep by Design
When InheritDelegatedPermissions is enabled on a blueprint, all Agent Identities from that blueprint automatically inherit all delegated permissions that an admin has consented for the Blueprint Principal.
Scenario: An admin consents Mail.ReadWrite and Files.ReadWrite.All on the Blueprint Principal — because a single use case requires both. With InheritDelegatedPermissions, all Agent Identities from this blueprint now receive those permissions — including ones that only need calendar data.
4. Token Flows — The technical core
The most critical question for every Identity Admin: Under whose identity does the agent operate when accessing resources? The answer depends entirely on the token flow — and on who is the target of a Conditional Access policy.
Attended / OBO Flow (on-behalf-of)
Use case: agent operates in the context of a signed-in user. The user is actively interacting with the agent.
The agent cannot do more than the user. That sounds secure — but only if the principle of least privilege applies to the user. In practice, many users hold far more permissions than their job requires. An agent in OBO flow inherits that entire overprivilege scope.
In the OBO flow, the agent inherits all permissions of the user — not just the ones the agent itself declared. If an agent declares Mail.Read as a delegated permission but the authenticated user also holds Files.ReadWrite.All and Teams.ReadWrite.All, a compromised agent token can potentially leverage those extended scopes. Cleaning up user overprivilege is no longer a governance recommendation in the context of AI agents — it is a necessity.
Unattended / Application-Only Flow (Client Credentials)
Use case: agent operates without a signed-in user — autonomous background processes, batch operations, scheduled tasks.
No user context means no natural permission ceiling. Application permissions with the .All suffix apply tenant-wide — an agent with Mail.ReadWrite.All can access the mailboxes of every user in the tenant without a single user ever signing in. Every .All permission is a potential tenant-wide data leak. To audit these permissions, check out my tool “Consentra”, available directly on this site, which generates an HTML report of all application permissions in your tenant.
5. Graph API Permissions: Delegated vs. Application
Microsoft Graph is the primary API through which agents access M365 data. The permission model is the single most important factor in an agent’s risk profile.
| Type | Description | Risk Profile |
|---|---|---|
| Delegated Permissions | Agent acts within the signed-in user’s scope. User.Read reads the profile of the signed-in user. | Limited by user context. Safer, but user overprivilege propagates. |
| Application Permissions | Agent acts without user context. Mail.ReadWrite.All reads/writes mailboxes of all users in the tenant. | Tenant-wide scope. Highest risk profile. No natural ceiling. |
Resource-Specific Consent (RSC) restricts Graph permissions to specific Teams or SharePoint sites rather than acting tenant-wide. Instead of Files.ReadWrite.All → Files.ReadWrite on a specific SharePoint site. Available for Teams and SharePoint scenarios — should be used wherever RSC is supported.
6. Security Threat Landscape — Real CVEs, Real Techniques
The following examples make one thing clear: AI agent security is not a theoretical problem.
CVE-2025-32711 “EchoLeak” — Zero-Click Data Exfiltration (CVSS 9.3, Critical)
Discovered: Aim Security, June 2025. Patched: Server-side by Microsoft, no client action required.
EchoLeak requires no opened attachments, no clicked links. The email alone is sufficient. Classic perimeter security, endpoint AV, and firewalls are completely ineffective against this attack type — the exploit operates entirely in the natural language space, not on the network.
CoPhish — OAuth Token Theft via Copilot Studio (Datadog Security Labs, October 2025)
No CVE at the time of disclosure. The technique is trivially reproducible and uses exclusively legitimate Microsoft infrastructure.
The domain copilotstudio.microsoft.com is entirely legitimate — no phishing indicator, no browser warning. The OAuth consent screen looks identical to a genuine flow. Application Administrators are the highest-value targets, as they can consent to delegated permissions without policy restrictions.
Detection: Entra Audit Logs → Consent to application. Copilot Studio Audit → PowerPlatform workload, operation: BotComponentUpdate, PropertyCollection likely contains *.topic.Signin.
HTTP Connector Tenant Isolation Bypass (Zenity Research, 2025)
Power Platform’s HTTP Connector bypasses Tenant Isolation policies by design. The platform does not dynamically validate cross-tenant identities at runtime — it relies on static bearer token values.
A flow or agent carrying a token from an external Microsoft tenant can access data cross-tenant even when Tenant Isolation is active. This enables cross-tenant data exfiltration with no straightforward detection path.
7. The right identity mindset for AI agents
Anyone managing AI agents in Microsoft ecosystems needs to expand their threat model:
1. Every agent is an identity — not just a “new” feature.
A Copilot Studio agent that can read emails is a Service Principal with Mail.ReadWrite permission. It is subject to the same governance requirements as any other non-human identity — with the difference that it autonomously decides when and how to use that permission.
2. The agent inherits your security debt. Poor access hygiene for users → over-privileged OBO flows. Inadequate MFA policies → agents can often impersonate users by design.
3. Shadow agents are the new shadow IT. Any M365 user with Copilot Studio access can create an agent, connect it to enterprise APIs, and make it available across the entire tenant — without IT involvement. The number of agents in an enterprise tenant grows faster than visibility over them. The first step in any agent security initiative is: inventory.
Preview: Part II
That brings us to the end of Part I. In the next part of this series, we move from anatomy to visibility: How do you inventory all agents in a tenant? Which logging sources deliver which signals? What do the necessary licenses actually cost? And how do you build a continuous agent monitoring workflow — from discovery to Sentinel alert.
References
- Microsoft Entra Agent ID Platform — Agent Identity Blueprints
- Entra Agent ID — Agent Identity Service Principals
- Azure AI Foundry — Agent Identity Concepts
- Azure AI Foundry — Agent-to-Agent Authentication
- Copilot Studio — Entra Agent Identities
- Microsoft Graph — Declarative Agent Architecture
- Microsoft Security Blog — Top 10 Copilot Studio Agent Security Risks
- Microsoft Security Blog — Prompts Become Shells: RCE in AI Agent Frameworks
- EchoLeak — CVE-2025-32711 Research Paper
- Datadog Security Labs — CoPhish
- Zenity Research — HTTP Connector Tenant Isolation Bypass
- Microsoft Graph Best Practices — Permissions
- Microsoft Agent Framework (GitHub)