Agenten befinden sich bereits in Ihrem Tenant. So behalten Sie die Kontrolle über sie

Agenten befinden sich bereits in Ihrem Tenant. So behalten Sie die Kontrolle über sie.

In den ersten zwei Monaten der Vorschauversion von Microsoft Agent 365 gab Microsoft an, dass zig Millionen Agenten in der Agent 365 Registry aufgetaucht sind. Diese Zahl war keine Prognose sie repräsentierte tatsächlich Agenten, die in teilnehmenden Kundenumgebungen sichtbar waren.

Ein Unterschied ist jedoch sofort von Bedeutung: Ein Eintrag in der Agent 365 Registry ist nicht zwangsläufig eine Identität in Microsoft Entra Agent ID.

Agent 365 kann Microsoft-, Drittanbieter-, gemeinsam genutzte und unverwaltete Agenten inventarisieren. Microsoft Entra zeigt und verwaltet die Teilmenge, die über eine Entra-Agentenidentität verfügt. Ältere Copilot Studio-Agenten authentifizieren sich unter Umständen weiterhin über herkömmliche Dienstprinzipale (Service Principals), und Drittanbieter- oder benutzerdefinierte Agenten müssen in der Regel erst registriert, synchronisiert oder instrumentiert werden, bevor sie den vollständigen Satz an Agent 365- und Agent ID-Kontrollen erhalten.

Für Identitäts- und Sicherheitsadministratoren besteht die erste Aufgabe daher nicht darin, anzunehmen, dass jeder Registry-Eintrag bereits verwaltet wird. Vielmehr geht es darum, zu ermitteln, welche Agenten existieren, welche Identitäten sie verwenden und welche Kontrollen tatsächlich auf sie angewendet werden.

Was Microsoft Entra Agent ID geschaffen hat

Microsofts zentrale Designentscheidung bestand nicht darin, ein weiteres KI-Verwaltungsportal zu bauen. Sie bestand darin, KI-Agenten als Identitäten zu behandeln.

Genau wie Benutzer, Anwendungen und Workloads über Identitäten in Entra ID verfügen, besitzen Agenten nun eigene Identitätsobjekte, die über bestehende Unternehmenskontrollen verwaltet, überwacht, mit Eigentümerschaft versehen und abgesichert werden können. Im Zentrum des Modells steht der Agent Identity Blueprint, der als übergeordnetes Objekt für eine oder mehrere Agentenidentitäten fungiert.

Eine Agentenidentität ist ein spezialisierter Dienstprinzipal, der aus einer Agent Identity Blueprint erstellt wird. Die Authentifizierung ist in der Blueprint verankert. Sie enthält die Anmeldeinformationen und die Authentifizierungskonfiguration, mit denen Token im Namen der erstellten Agentenidentitäten abgerufen werden.
Stellen Sie sich die Blueprint als Vertrauensanker und Vorlage vor. Die Agentenidentität ist die Laufzeitinstanz.

Ein Blueprint kann viele Agentenidentitäten erstellen, die alle gemeinsame Authentifizierungs- und Identitätsmerkmale teilen, während individuelle Berechtigungen und Konfigurationen dort möglich bleiben, wo sie erforderlich sind.

Microsofts Ziel ist es nicht, Agenten einzeln zu verwalten. Es geht darum, Governance, Eigentümerschaft und Sicherheitskontrollen im großen Maßstab zu etablieren.

Das Objektmodell verstehen

Agent Identity Blueprint
Das übergeordnete Objekt, das Authentifizierungseinstellungen, Eigentümerschaft, Sponsoring, Berechtigungen und gemeinsame Konfiguration definiert.

Agent Identity Blueprint Principal
Die Dienstprinzipal-Repräsentation des Blueprints innerhalb des Tenants. Er ist im Hintergrund an der Berechtigungszuweisung und tokenbezogenen Vorgängen beteiligt.

Agent Identity
Die eigentliche nicht-menschliche Identität, die ein KI-Agent zum Zugriff auf Ressourcen verwendet.

Agent User (optional)
Manche Agenten erhalten eine benutzerähnliche Repräsentation, anstatt ausschließlich als Dienstprinzipale zu existieren. Dies ermöglicht ihnen die natürliche Teilnahme an Arbeitsabläufen wie Teams, Outlook und anderen Kollaborationsumgebungen, in denen ein Anzeigename, eine Präsenz oder eine Persona wünschenswert ist.

Eigentümerschaft ist wichtiger als Technologie

Sowohl Blueprints als auch Agentenidentitäten unterstützen Governance-Beziehungen über Owner (Eigentümer) und Sponsoren.

• Owner verwalten und administrieren den Agenten.
• Sponsoren liefern die geschäftliche Rechenschaftspflicht.

Der Unterschied ist wichtig. Ein Owner kann einen Agenten konfigurieren. Ein Sponsor beantwortet die Frage, die sich jeder Auditor, jedes Governance-Team und jeder Incident Responder irgendwann stellt: Warum existiert dieser Agent, und sollte er weiterhin Zugriff haben?

Mit wachsender Agentenpopulation wird das Wissen darüber, wer verantwortlich ist, ebenso wichtig wie das Wissen darüber, welche Berechtigungen erteilt wurden.

Die zwei Zugriffsmodelle, die Sie verstehen müssen

Zwei Zugriffsmuster bestimmen, wie Agenten mit Systemen interagieren und was bei einem Angriff tatsächlich offengelegt würde.

Autonomer Modus
Agenten agieren mit Berechtigungen auf App-Ebene, wie zum Beispiel:

• Microsoft Graph-Anwendungsberechtigungen
• Entra-App-Rollen
• Azure RBAC-Zuweisungen
• API-spezifische Dienstberechtigungen

Der Agent agiert eigenständig und kann auch ohne angemeldeten Benutzer weiterarbeiten.

On-Behalf-Of (OBO)-Modus
Der Agent agiert mit delegierten Berechtigungen, die vom angemeldeten Benutzer geerbt werden. In diesem Modell ist der Zugriff des Agenten durch die eigenen Berechtigungen des Benutzers begrenzt. Zu verstehen, welches Modell ein Agent verwendet, sollte einer der ersten Schritte in jeder Governance- oder Risikobewertung sein.

Warum das alte Identitäts-Playbook nicht vollständig übertragbar ist

Agenten melden sich nicht interaktiv an. Kein Browser, keine MFA-Aufforderung, keine Geräteprüfung, keine Sitzung mit einem Login-Bildschirm, vor den man eine Conditional-Access-Herausforderung setzen könnte. Die Authentifizierung erfolgt Maschine-zu-Maschine, Token-zu-Token. Das bedeutet, dass ein erheblicher Teil des für Menschen entwickelten Zero-Trust-Werkzeugkastens Step-up-Authentifizierung, Geräte-Compliance, anmeldebasiertes Risiko basierend auf IP- und Browser-Fingerabdruck schlicht nicht auf die gleiche Weise anwendbar ist. Die aktuellen Conditional-Access-Funktionen für Agenten sind eingeschränkter als jene, die für menschliche Benutzer verfügbar sind, und konzentrieren sich primär auf Richtliniendurchsetzung, risikobasierte Kontrollen und Zugriffs-Governance statt auf interaktive Authentifizierungsherausforderungen.

Was tatsächlich neu ist, ist das Risikoprofil:
• Agenten-Wildwuchs (Agent Sprawl) entsteht, weil jeder mit einer Copilot Studio-Lizenz einen Agenten erstellen kann.
• Überberechtigte Agenten, verursacht durch zu weit gefasste Berechtigungsumfänge.
• Missbrauch von Tools (Tool Misuse) entsteht, wenn ein Agent manipuliert wird, ein legitimes Tool für einen illegitimen Zweck aufzurufen.
• Und Prompt Injection, die in der Welt der menschlichen Identität kein sauberes Äquivalent hat es handelt sich um einen Angriff auf die Denkfähigkeit (Reasoning) des Agenten, nicht auf seine Anmeldeinformationen.

Microsoft-Produkt- und Funktionsmatrix für die Governance von KI-Agenten

Microsoft hat dafür nicht ein einziges Produkt gebaut. Es hat drei bestehende Produkte erweitert: Entra, Purview, Defender und ein viertes darübergesetzt, um sie gemeinsam zu verwalten.

Eine Bereitstellungsreihenfolge, die funktioniert

1. Mit dem Inventar beginnen (Agent 365): Ermitteln Sie Ihre Ausgangspopulation. Trennen Sie Registry-Only-Agenten, unverwaltete Agenten und Entra-verwaltete Agenten, bevor Sie auch nur eine einzige Richtlinie schreiben.

2. Sponsoren und Owner zuweisen: Jeder Blueprint und jede Identität sollte sowohl einen technischen Owner als auch einen geschäftlichen Sponsor haben. Incident Response beginnt mit Rechenschaftspflicht.

3. Dauerhafte Berechtigungen zu Access Packages migrieren: Entfernen Sie direkte Rollenzuweisungen an Agenten. Fassen Sie Berechtigungen im Entitlement Management mit definierten Ablauffristen zusammen.

4. Conditional Access im Report-Only-Modus bereitstellen: Zielen Sie auf die Bedingung "Agentenrisiko" (mit Fokus auf API-Spitzen und abnormales Token-Verhalten) und legen Sie zusätzlich Richtlinien für benutzerdefinierte Sicherheitsattribute für sensible Ziele darüber. Werten Sie die Report-Only-Protokolle aus, um die Basis-Telemetrie der Agenten zu verstehen, bevor Sie die Durchsetzung aktivieren.

5. Purview DSPM for AI aktivieren: Aktivieren Sie die Datenprotokollierung und Prompt-Leitplanken parallel zu den Identitätskontrollen, um sofort Audit-Trails zu erfassen.

6. Defender Activity Mapping aktivieren: Bilden Sie die Kommunikationswege zwischen Agenten ab, sobald Ihre Flotte die Grenzen manueller Nachverfolgung überschreitet.

7. In Agent 365 konsolidieren: Nutzen Sie die Kontrollebene, um operative Signale über Ihr verwaltetes Agenten-Inventar hinweg zu aggregieren.

Was Entra für Sie noch nicht leistet

Ein paar Lücken sollte man von Anfang an kennen, sonst überraschen sie einen mitten im Rollout. Benutzerdefinierte Entra-Rollendefinitionen unterstützen derzeit keine Aktionen zur Verwaltung von Agentenidentitäten, sodass Sie für diesen Objekttyp keine fein abgestufte, benutzerdefinierte Admin-Rolle erstellen können, wie Sie es bei anderen Objekttypen könnten. Der standardmäßige Admin-Consent-Workflow verhält sich bei Berechtigungen, die von Agentenidentitäten angefordert werden, nicht korrekt wird die Zustimmung eines Benutzers durch risikobasiertes Step-up blockiert, gibt es keine Umgehungslösung; das markierte Risiko muss zunächst behoben werden, oder der Tenant-Administrator muss die Berechtigung direkt erteilen.

Und Audit-Protokolle unterscheiden standardmäßig nicht zwischen Agentenidentitäten und anderen Identitätstypen alles landet in der Kategorie ApplicationManagement. Wenn Sie also SIEM-Abfragen oder Compliance-Berichte erstellen, müssen Sie selbst nach dem Objekttyp filtern, statt eine saubere "Agent"-Kennzeichnung von Haus aus zu erwarten.