Zero Trust für KI-Agenten, Teil 3: Identität und Zugriff mit Entra Agent ID

In Teil 2 haben wir Copilot Studio und Microsoft Foundry abgesichert. Beide Plattformen erzeugen für ihre Agenten Identitäten in Microsoft Entra. Und damit sind wir bei dem Thema, mit dem jede Zero-Trust-Reise beginnt: der Identität. Wer unsere Conditional-Access-Serie kennt, wird vieles wiedererkennen – aber Agenten haben ein paar Besonderheiten, die ihr kennen müsst.

Warum Agenten eigene Identitäten brauchen

Früher liefen Automatisierungen meist über App-Registrierungen und Dienstprinzipale. Diese wurden jedoch für langlebige Anwendungen mit klarem Besitzer entworfen. Agenten sind anders: Sie entstehen schnell, oft durch Mitarbeitende selbst, und manche existieren nur für eine einzige Aufgabe. Microsoft nennt vier Probleme, die eigene Agenten-Identitäten lösen sollen:

1. Aktionen von Agenten müssen sich klar von denen von Menschen und Anwendungen unterscheiden lassen.
2. Agenten sollen passgenaue Rechte bekommen – nicht mehr als nötig.
3. Agenten dürfen keinen Zugang zu den kritischsten Rollen und Systemen erhalten.
4. Die Verwaltung muss mit sehr vielen, kurzlebigen Agenten skalieren.

Entra Agent ID im Überblick

Das Framework Microsoft Entra Agent ID erweitert Entra um Identitäten speziell für KI-Agenten. Es funktioniert mit Agenten von Microsoft – etwa aus Copilot Studio, Foundry, Teams oder Agent 365 – und mit Agenten anderer Plattformen wie AWS Bedrock oder n8n.

Die wichtigsten Begriffe:

• Agenten-Identität: ein spezieller Dienstprinzipal, der den Agenten repräsentiert. Sie hat keine eigenen Anmeldedaten – kein Kennwort, kein Geheimnis.
• Blueprint (Vorlage): die Schablone für eine ganze Klasse von Agenten. Sie hält die Anmeldedaten und erzeugt daraus Tokens für die einzelnen Agenten-Identitäten. Richtlinien, die auf einen Blueprint zielen, gelten automatisch für alle Agenten, die daraus entstehen – auch für künftige.
• Sponsor: der Mensch oder die Gruppe, die für den Agenten verantwortlich ist. Bei einem Sicherheitsvorfall ist das der erste Ansprechpartner.
• Agenten-Benutzerkonto (optional): ein Benutzerkonto, das fest mit genau einer Agenten-Identität verbunden ist. Es wird nur gebraucht, wenn ein System zwingend ein Benutzerobjekt verlangt – etwa für ein Postfach.

Agenten-Identitäten gelten übrigens nur in dem Mandanten, in dem sie erstellt wurden. Ihr findet sie im Entra Admin Center unter Entra ID > Agents > Agent identities.

Die drei Zugriffsmuster

Wie schon in Teil 1 kurz angesprochen, entscheidet das Zugriffsmuster darüber, welche Richtlinie greift:

Muster	Wer steht im Token?	Welche Richtlinie greift?
Im Auftrag eines Benutzers	Benutzer als Subjekt, Agent als Akteur	Eure bestehenden Benutzer-Richtlinien
Autonom	Die Agenten-Identität	Richtlinien mit Zuweisung „Agenten-Identitäten“
Agenten-Benutzerkonto	Das Agenten-Benutzerkonto	Richtlinien mit Zuweisung „Agenten-Benutzer“

Conditional Access für Agenten

Conditional Access für Agenten erweitert die bekannte Richtlinien-Engine. Sie bewertet Signale wie Agenten-Kontext und Risiko und entscheidet dann, ob ein Agent ein Token bekommt. Weil Agenten keine MFA bestätigen können, sehen die Richtlinien jedoch anders aus als für Menschen: Statt „MFA verlangen“ heißt es meistens „erlauben, wenn freigegeben – sonst blockieren“.

Empfohlene Richtlinien

1. Nur freigegebene Agenten zulassen. Microsoft weist im Zero Trust Assessment ausdrücklich darauf hin: Ohne mindestens eine Richtlinie nach dem Muster „blockieren, außer freigegeben“ wird jede Token-Anforderung eines Agenten standardmäßig erlaubt. Kennzeichnet freigegebene Agenten mit benutzerdefinierten Sicherheitsattributen und blockiert alle anderen.
2. Agenten mit hohem Risiko blockieren. Entra ID Protection bewertet auch Agenten – etwa bei ungewöhnlichen Zugriffen oder auffälligen Anmeldespitzen. Eine Richtlinie mit der Bedingung Agentenrisiko: Hoch und der Aktion Blockieren schneidet kompromittierte Agenten sofort ab.
3. Nicht-produktive Agenten von Produktionsdaten fernhalten. Mit Attributen wie Environment, Department oder DataSensitivity trennt ihr Test- und Produktionsagenten sauber.
4. Agenten-Benutzerkonten gesondert abdecken. Legt eigene Richtlinien mit der Zuweisung Agenten-Benutzer an.
5. Bestehende Richtlinien prüfen. Breite Richtlinien wie „MFA für alle“ können Agenten-Abläufe unbeabsichtigt blockieren. Schließt Agenten dort gezielt aus und deckt sie über eigene Richtlinien ab.

Wie bei Menschen gilt auch hier: Jede neue Richtlinie zuerst im Nur-Bericht-Modus testen, erst dann einschalten. Wie das geht, beschreiben wir in Teil 5 der Conditional-Access-Serie.

Grenzen, die ihr kennen solltet

• Conditional Access schützt nur Ressourcen, die über Microsoft Entra angemeldet werden. Greift ein Agent per API-Schlüssel zu, umgeht er die Richtlinien vollständig. Ein weiterer Grund, Schlüssel durch Entra-Authentifizierung zu ersetzen.
• Sind die Sicherheitsstandards (Security Defaults) aktiv, greift Conditional Access nicht – auch nicht für Agenten.
• Einige Funktionen, etwa das Agentenrisiko und die Zuweisung für Agenten-Benutzer, sind noch in der Vorschau.

Minimale Rechte für Agenten

Conditional Access entscheidet also, ob ein Agent ein Token bekommt. Was er damit tun darf, bestimmen seine Berechtigungen. Microsoft empfiehlt dafür im Muster „Least privilege for AI agents“:

• Eine eigene Identität pro Agent mit benanntem Sponsor und dokumentiertem Zweck.
• Aufgabenbezogene Rechte statt breiter Rollen – ein Agent, der Dokumente zusammenfasst, braucht nur Lesezugriff auf bestimmte Sites.
• Freigabelisten für Werkzeuge und Aktionen: Was nicht geprüft ist, ist verboten.
• Kritische Aktionen absichern, etwa durch eine Freigabe durch Menschen oder zeitlich begrenzte Rechte über Privileged Identity Management.
• Rückzug testen: Lässt sich ein Agent im Ernstfall schnell deaktivieren, lassen sich seine Tokens widerrufen und seine Rechte entfernen?

Governance über den Lebenszyklus

Agenten sammeln jedoch über die Zeit Rechte an – genau wie Menschen. Mit Microsoft Entra ID Governance lassen sich Agenten deshalb in dieselben Prozesse einbinden:

• Zugriffspakete mit Ablaufdatum, damit Rechte nicht länger bestehen als nötig.
• Sponsoren und Besitzer werden gepflegt, sodass keine verwaisten Agenten entstehen.
• Zugriffsprüfungen, in denen Sponsoren regelmäßig bestätigen, dass ein Agent seine Rechte noch braucht.

Was es kostet

Die Agenten-Funktionen von Entra sind an Microsoft Agent 365 gekoppelt:

Funktion	Voraussetzung laut Microsoft
Conditional Access für Agenten	Microsoft 365 E7 oder Agent 365 zusammen mit mindestens Entra ID P1 bzw. Microsoft 365 E3
Risikobasierte Richtlinien für Agenten	Zusätzlich Entra ID P2 bzw. Microsoft 365 E5
ID Governance für Agenten	Microsoft 365 E7 oder Agent 365 zusammen mit mindestens Entra ID P1 bzw. Microsoft 365 E3

Agent 365 wird pro Benutzer lizenziert. Prüft wie immer die aktuellen Produktbeschreibungen oder sprecht mit eurem Microsoft-Partner. Einen Überblick über die übrigen Lizenzen findet ihr in Teil 7 unserer Zero-Trust-Serie.

Wie es weitergeht

Identität und Rechte sind allerdings nur die halbe Miete. Die andere Hälfte sind die Daten, auf die Agenten zugreifen. In Teil 4 geht es um Oversharing, Vertraulichkeitsbezeichnungen und Data Loss Prevention – also darum, eure Daten zu schützen, bevor die KI sie findet.

Offizielle Microsoft-Quellen

• Was ist Microsoft Entra Agent ID?
• Agenten-Identitäten in Microsoft Entra Agent ID
• Conditional Access für Agenten
• Autonome Agenten mit Conditional Access schützen
• Best Practices für Microsoft Entra Agent ID
• Minimale Rechte für KI-Agenten
• Governance für Agenten-Identitäten