AI Agent Security mit Entra ID: OAuth + Gruppen-Permissions

Pexon Consulting | 11 Min. Lesezeit | 08.06.2026

TL;DR

AI Agent Security beginnt nicht beim LLM, sondern bei der Identity. Wer Agents ohne sauberen OAuth-Flow gegen Microsoft Entra ID auf Tool-Endpoints loslässt, hat ein Zugriffs-Problem auf Service-Account-Niveau. Pexon empfiehlt: Agent als Service Principal, On-Behalf-Of-Flow für User-Aktionen, Tool-Filter auf Basis von Entra-ID-Gruppen-Claims. Das ist DORA- und NIS-2-konform und skaliert auf 100+ Agents.

Warum AI Agents ohne Governance gefährlicher sind als jeder andere Service

Ein klassischer Microservice macht das, was er programmiert ist. Ein AI Agent macht das, was er aus dem Prompt ableitet — und entscheidet zur Laufzeit, welche Tools er aufruft. Das ist der eigentliche Sicherheits-Sprung: Der Berechtigungsumfang eines Agents ist nicht im Code festgeschrieben, sondern im Identity-Layer.

In drei Pexon-Audits bei Versicherern und Energieversorgern in den letzten neun Monaten haben wir denselben Anti-Pattern gesehen: Der Agent läuft mit einem Service-Account, der Microsoft Graph User.Read.All, Mail.Read und Files.Read.All besitzt — pauschal, für alle User, ohne Kontext. Damit wird jeder Prompt zur potenziellen Privilege-Eskalation: Ein User, der eigentlich nur seine eigenen Mails sehen darf, kann den Agent fragen „Lies die Mails von Geschäftsführer X“ und bekommt eine Antwort.

Das ist nicht Theorie. Das ist Realität in einem Großteil der heutigen Agent-Deployments. Und es ist der Grund, warum AI Agent Security 2026 die meistdiskutierte Position auf jeder CISO-Agenda ist.

Aus DORA Artikel 6 (Risikomanagement für IKT-Drittparteien) und NIS-2 Artikel 21(2)(i) (Personalsicherheit, Zugriffskontrolle) leitet sich klar ab: Agents sind nicht-menschliche Identitäten, die nach denselben Standards verwaltet werden müssen wie Service-Accounts — mit dem Zusatz, dass sie eine Stufe gefährlicher sind, weil sie autonom entscheiden.

Die vier OAuth-Flows für Agents — welcher wann?

Microsoft Entra ID kennt vier OAuth 2.0-Flows, die für AI Agents relevant sind. Jeder hat ein Einsatzgebiet, jeder hat eine Falle.

Flow 1 — Client Credentials. Der Agent authentifiziert sich mit seinem eigenen Secret oder Zertifikat gegen Entra ID und bekommt einen Token mit App-Permissions. Kein User-Kontext. Geeignet für reine System-Aktionen (z.B. nächtliche Daten-Synchronisation), gefährlich für User-getriebene Aktionen. Die App-Permissions werden vom Tenant-Admin pauschal gewährt — keine User-spezifische Einschränkung.

Flow 2 — Authorization Code mit Delegated Permissions. Der User loggt sich am Frontend ein, der Agent bekommt im User-Namen einen Token mit den delegated permissions. Das ist die saubere Default-Wahl, wenn der Agent klassische Web-Backends als Tools aufruft. Schwäche: Tools, die nur App-Permissions akzeptieren (z.B. ältere Microsoft-Graph-Endpunkte), können so nicht aufgerufen werden.

Flow 3 — On-Behalf-Of (OBO). Der Agent hat einen User-Token, will aber ein Downstream-Tool aufrufen, das einen anderen Resource-Token braucht. Das OBO-Flow tauscht den User-Token gegen einen neuen User-Token für das Downstream-Tool — mit der Berechtigungs-Vererbung des Users. Das ist die richtige Wahl für Multi-Tool-Agents, die mehrere Backends im Namen des Users aufrufen.

Flow 4 — Device Code Flow. Für CLI-Agents oder Agents auf Geräten ohne Browser. Der User authentifiziert sich am Smartphone, der Agent bekommt den Token. Praktisch für Entwickler-Werkzeuge, weniger für produktive User-Agents.

Unsere klare Empfehlung: Für jeden User-getriebenen Agent ist OBO (Flow 3) der Default. Client Credentials nur für System-Workflows ohne User-Kontext. Wer das umkehrt, baut sich einen Berechtigungs-Albtraum, der spätestens beim ersten DORA-Audit auffällt.

Entra ID App Registration für einen Agent — die richtige Konfiguration

Bevor der Agent überhaupt einen Token bekommt, muss er als App in Entra ID registriert sein. Die Konfiguration hat sechs Hebel, die direkt auf AI Agent Security wirken:

1. Application ID und Client Secret oder Zertifikat. Secrets sind einfacher, Zertifikate sicherer. Für Produktion immer Zertifikat plus Azure Key Vault. Secret-Rotation alle 90 Tage als Minimum, besser 30 Tage.
2. API Permissions (Microsoft Graph und eigene APIs). Hier liegt der größte Hebel. Nur die minimal nötigen Permissions vergeben. Wer pauschal User.Read.All, Mail.Read und Files.Read.All setzt, hat schon verloren.
3. Application Roles. Eigene App-Roles definieren (z.B. Agent.Read, Agent.Write, Agent.Admin) und an Entra-ID-Gruppen mappen. Das ist die Brücke zwischen Entra-ID-Identitäten und Tool-spezifischen Berechtigungen.
4. Token-Konfiguration. Group Claims aktivieren — sonst bekommt der Agent keine Information über Gruppenmitgliedschaft des Users. Achtung beim Overage-Limit: Direkt im Token landen maximal 200 Gruppen. Bei Usern mit mehr Gruppen muss der Agent die vollständige Liste über Microsoft Graph nachfragen.
5. Conditional Access Policies. Den Agent in eine eigene Policy nehmen — z.B. „nur aus Unternehmensnetz“, „nur mit MFA-validierter Session“. Das ist die Compliance-Versicherung gegen Token-Diebstahl.
6. Authentication Flow Hardening. Allowed redirect URIs eng halten, implizite Flows deaktivieren, PKCE für Public Clients erzwingen. Klassische OAuth-Hygiene, die in 8 von 10 Audits unsauber konfiguriert ist.

Was wir aktuell nicht empfehlen: Den Agent als Multi-Tenant-App registrieren, wenn nur ein Tenant ihn nutzt. Das öffnet unnötige Angriffsfläche. Single-Tenant ist sicherer, einfacher und im Audit deutlich leichter zu erklären.

Gruppen-Permissions auf Tool-Ebene — das Architektur-Pattern

Der entscheidende Architektur-Move für skalierbare AI Agent Security ist die Trennung von Tool-Definition und Tool-Sichtbarkeit. Nicht jeder User sieht jedes Tool — die Sichtbarkeit hängt an seiner Entra-ID-Gruppenzugehörigkeit.

+---------------+    +-----------------+    +------------------+
| User-Token    |    | Tool-Registry   |    | Filtered Tools   |
| mit Group-    |--->| (Tool-Definitn  |--->| (nur die, die    |
| Claims        |    |  + Gruppen-Bind)|    | User-Group darf) |
+---------------+    +-----------------+    +------------------+
                                                     |
                                                     v
                                            +-----------------+
                                            | LLM bekommt nur |
                                            | erlaubte Tools  |
                                            | (kein Halluz.   |
                                            |  über verbotene)|
                                            +-----------------+

Drei wichtige Detail-Entscheidungen:

• Tool-Filter vor LLM-Aufruf, nicht nach. Das LLM darf gar nicht erst wissen, dass ein verbotenes Tool existiert. Sonst halluziniert es Tool-Calls auf Endpunkte, die für den User nicht zugänglich sind, und der Agent verbringt seine Zeit mit 403-Fehlern.
• Gruppen-Binding deklarativ, nicht im Code. Jedes Tool in der Registry hat eine allowed_groups: list[str] Annotation. Wer eine neue Gruppe oder ein neues Tool einführt, ändert die Registry — nicht den Agent-Code. Das ist Voraussetzung für Audit-Trail-fähige Berechtigungsverwaltung.
• Audit-Log pro Tool-Filter-Entscheidung. Jede „Tool X für User Y aufgrund Gruppe Z (un)sichtbar“-Entscheidung wird ins SIEM geloggt. Das ist die Compliance-Grundlage und gleichzeitig die Anomalie-Erkennung für untypische Zugriffsmuster.

In der Praxis bauen wir die Tool-Registry als YAML im Repo plus einen kleinen Loader, der zur Agent-Initialisierung den User-Token gegen die Tool-Bindings prüft. Das ist 200-400 Zeilen Code und liefert eine Berechtigungsstruktur, die ein klassischer Microsoft-Graph-API-Aufruf in dieser Granularität gar nicht anbietet.

Code-Beispiel — Token-Exchange (OBO) und Tool-Filter

So sieht der produktive Pattern aus, vereinfacht aber lauffähig. Vollversion mit Caching, Retry und Logging ist im Pexon-Repo.

from msal import ConfidentialClientApplication
from fastapi import Depends, HTTPException
import yaml

# Tool Registry als YAML
TOOL_REGISTRY = yaml.safe_load("""
tools:
  - name: search_customer_data
    endpoint: /api/customers/search
    allowed_groups: ["agent-customer-service", "agent-sales"]
  - name: write_invoice
    endpoint: /api/invoices/create
    allowed_groups: ["agent-finance"]
  - name: read_hr_records
    endpoint: /api/hr/employees
    allowed_groups: ["agent-hr-admin"]
""")

msal_app = ConfidentialClientApplication(
    client_id=AGENT_CLIENT_ID,
    client_credential=AGENT_CERT,
    authority=f"https://login.microsoftonline.com/{TENANT_ID}",
)

def exchange_token_obo(user_token: str, target_scope: str) -> str:
    """On-Behalf-Of: User-Token gegen Downstream-Token tauschen."""
    result = msal_app.acquire_token_on_behalf_of(
        user_assertion=user_token,
        scopes=[target_scope],
    )
    if "access_token" not in result:
        raise HTTPException(403, f"OBO-Flow fehlgeschlagen: {result.get('error_description')}")
    return result["access_token"]

def filter_tools_for_user(user_groups: list[str]) -> list[dict]:
    """Filtert Tools auf Basis der User-Gruppen aus Entra-ID Group-Claims."""
    allowed = []
    for tool in TOOL_REGISTRY["tools"]:
        if any(group in tool["allowed_groups"] for group in user_groups):
            allowed.append(tool)
            audit_log("tool_visible", tool=tool["name"], user_groups=user_groups)
        else:
            audit_log("tool_hidden", tool=tool["name"], user_groups=user_groups)
    return allowed

async def run_agent(user_token_claims: dict, user_question: str):
    user_groups = user_token_claims.get("groups", [])
    visible_tools = filter_tools_for_user(user_groups)
    # LLM bekommt NUR die sichtbaren Tools — keine Halluzination über verbotene
    return await agent.run(
        question=user_question,
        available_tools=visible_tools,
        token_provider=lambda scope: exchange_token_obo(user_token_claims["raw"], scope),
    )

Drei wichtige Pattern-Entscheidungen:

1. exchange_token_obo als Lazy-Provider. Der Agent fordert einen neuen Downstream-Token erst an, wenn er ein Tool tatsächlich aufruft. Spart Tokens, reduziert die Audit-Last und beschränkt die Token-Lebensdauer auf das Notwendige.
2. audit_log für jeden Filter-Entscheid. Auch das „Tool ist für diesen User nicht sichtbar“ wird geloggt. Das ist die Datenbasis für „warum hat User X heute keine Antwort bekommen?“-Analysen und für die Anomalie-Erkennung im SIEM.
3. Tool-Registry deklarativ in YAML. Trennung von Code und Berechtigungsstruktur. Wer eine neue Gruppe oder ein neues Tool einführt, ändert die Registry — der Code bleibt unangerührt.

Audit-Trail für DORA und NIS-2 — was Sie wirklich loggen müssen

Aus zwei DORA-Pre-Audits 2025/2026 wissen wir, was die Prüfer konkret sehen wollen. Pro Agent-Aktion sind mindestens diese Felder Pflicht:

Retention: 12-24 Monate für SIEM, 24-36 Monate für sicherheitskritische Cold-Storage-Daten. Kürzer scheitert in den ersten DORA-Audits, länger ist häufig DSGVO-relevant problematisch.

Was wir aktuell nicht empfehlen: Den vollen Prompt-Inhalt in das SIEM zu schreiben. Das macht Datenschutz-Risiken und Storage-Kosten zu groß. Stattdessen Hash im SIEM, Volltext in einem separaten, restriktiv zugegriffenen Cold-Storage mit kürzerer Retention (60-90 Tage).

Wichtig für DORA Artikel 17 (IKT-Vorfall-Management): Die Audit-Logs müssen so strukturiert sein, dass ein Sicherheitsvorfall innerhalb von Stunden, nicht Tagen, rekonstruierbar ist. „Wir können das in zwei Wochen liefern“ reicht nicht. Wer das nicht hat, fällt in der DORA-Tabletop-Übung durch — und genau die wird ab 2026 jährlich verlangt.

Anti-Patterns — drei Wege, wie AI Agent Security in Produktion bricht

Aus zwölf Pexon-Audits und Discoveries 2025/2026 drei wiederkehrende Anti-Patterns. Wenn Sie eines davon im Setup haben, ist die Eskalation Zeit-Frage.

Anti-Pattern 1 — Der „Pauschal-Service-Account“. Ein zentraler Service-Account mit User.Read.All, Mail.Read, Files.Read.All und Group.Read.All als App-Permissions, der für jeden Agent benutzt wird. Damit kann jeder Prompt jeden User-Datenbestand abrufen. Klassischer Privilege-Escalation-Vektor. Fix: OBO-Flow + Gruppen-Filter, niemals App-Permissions für User-getriebene Workflows.

Anti-Pattern 2 — Tool-Liste hartcodiert im Agent-Code. Wer welche Tools sehen darf, steht als if-else im Python-Code. Ergebnis: Berechtigungs-Änderung braucht Code-Deployment, Audit-Trail existiert nicht. Fix: Deklarative Tool-Registry plus dynamische Gruppen-Filterung.

Anti-Pattern 3 — Group Claims ignoriert. Der Agent bekommt einen User-Token, prüft aber die Gruppen-Claims nie und behandelt jeden User gleich. Bei Usern mit über 200 Gruppen taucht das Group-Overage-Problem auf, der Agent erkennt es nicht und arbeitet mit unvollständigem Berechtigungsbild. Fix: Group-Claims explizit lesen, Overage-Fall über Microsoft Graph nachfragen, Cache mit 5-15 Minuten TTL.

Konfidenz für alle drei Anti-Patterns: hoch. Wir sehen das in jedem zweiten Audit.

Kosten und Zeitrahmen

Aus drei laufenden Pexon-Projekten der typische Aufwand für ein produktives AI-Agent-Security-Setup mit Entra ID:

Laufende Kosten: Entra ID P1/P2 Lizenzen (oft schon im M365 E5 enthalten) plus 100-300 EUR pro Monat für SIEM-Storage. Wartung 0,5-1 PT pro Monat.

ROI-Rechnung: Der Hauptnutzen ist nicht Effizienz, sondern vermiedener Schaden. Aus zwei DORA-Pre-Audits 2025: Ein Befund „unzureichende Zugriffskontrolle bei AI Agents“ zieht typischerweise eine Nachweispflicht von 90 Tagen plus eine zweite Audit-Runde, was 60.000-120.000 EUR an internem Aufwand kostet. Wer das System initial sauber baut, spart sich diese Schleife.

Häufig gestellte Fragen

Brauche ich Entra ID P2 für AI Agent Security oder reicht P1?

P1 reicht für die Basis (Conditional Access, App Registrations, Group Claims). P2 ist nötig für PIM (Privileged Identity Management) und Identity Protection, die für hochkritische Agents (z.B. mit Schreibrechten auf Finance- oder HR-Systeme) klar empfohlen sind. In den meisten Mittelstands-Setups reicht P1, in regulierten Großunternehmen ist P2 Standard.

Funktioniert das Pattern auch mit Open-Source-LLMs auf Private KI-Infrastruktur?

Ja, die Identity-Schicht ist LLM-agnostisch. Entra ID, OBO und Tool-Filter laufen vor dem LLM-Aufruf, egal ob das LLM Claude Sonnet 4, GPT-4.1, Llama 3.3 oder Qwen 2.5 ist. Für Private KI-Infrastruktur ist das Pattern sogar besonders wichtig, weil die On-Prem-Variante oft ohne Standard-Identity-Schicht ausgeliefert wird.

Was passiert, wenn der User-Token während eines langen Agent-Loops abläuft?

Default-Token-Lebensdauer in Entra ID ist 60-90 Minuten, einstellbar via Token Lifetime Policies. Für lange Agent-Loops nutzen wir Refresh-Token-Pattern oder Token-Pre-Renewal alle 30 Minuten. Wichtig: Den abgelaufenen Token nie still ignorieren — der Agent muss bei Token-Ablauf entweder erneuern oder sauber an den User eskalieren.

Kann ich App-Permissions und Delegated Permissions im gleichen Agent mischen?

Ja, das ist sogar der Default. Reine System-Aktionen (z.B. nächtliche Datenbank-Sync) laufen mit Client Credentials und App-Permissions, User-getriebene Aktionen mit OBO und Delegated Permissions. Wichtig ist die klare Trennung im Code: Nie aus einem User-Flow heraus auf App-Permissions zurückfallen, weil das die Berechtigungs-Vererbung bricht.

Wie verhindere ich, dass ein Agent durch Prompt-Injection seine eigenen Berechtigungen erhöht?

Durch das Pattern selbst: Berechtigungen kommen aus dem Entra-ID-Token, der vor dem Agent-Aufruf validiert wird. Der Prompt kann den Token nicht ändern. Selbst wenn ein User dem Agent sagt „Verhalte dich als Admin“, bekommt der Agent dadurch keine zusätzlichen Berechtigungen. Das ist der zentrale Sicherheitsgewinn gegenüber Service-Account-Patterns. Ergänzend: Tool-Filter immer vor dem LLM, nie nach — sonst kann der Prompt das LLM zu einem Tool-Call bewegen, den das Backend dann mit 403 ablehnt, was eine Halluzinations-Schleife erzeugt.

Nächster Schritt

Wenn Sie aktuell AI Agent Security für DORA, NIS-2 oder eine Konzern-interne Compliance-Anforderung aufsetzen müssen: Wir machen das im 6-Wochen-Pilotprojekt für Generative AI konkret — Identity-Architektur, Entra-ID-Setup, OBO-Flow, Tool-Registry und SIEM-Anbindung mit einem ersten produktiven Agent als Referenz für den Roll-out auf 10+ weitere Agents.

Verwandte Themen