AI-Agent-Berechtigungsmodell: Benutzeridentität, Tool-Rechte, Audit-Logs und Secret-Isolation

Ein Team gibt demselben Agenten denselben Admin-Token, weil „es ja nur ein internes System ist“. Dann stellt Benutzer A eine Abfrage, und der Agent liest mit Admin-Identität den CRM-Datensatz von Benutzer B. Ein Agent mit kaputten Berechtigungen ist gefährlicher als gar kein Agent.

Das ist kein hypothetischer Sonderfall. MCP Security Best Practices markiert token passthrough ausdrücklich als Anti-Pattern: Es umgeht Sicherheitskontrollen, zerstört die audit trail und verletzt trust boundaries. Das OWASP AI Agent Security Cheat Sheet zählt „tool abuse and privilege escalation“ ebenfalls zu den Kernrisiken.

Die Frage lässt sich auf drei Punkte reduzieren: Wen repräsentiert der Agent, wodurch darf er aufrufen, und worauf darf er zugreifen? Im Folgenden steht das vollständige Engineering-Modell: Identity-Mapping-Tabelle, Tool-Berechtigungsfelder, Kernschritte für den Secret Vault, Audit-Log-Schema mit Maskierungsregeln, Entscheidungs­tabelle, Troubleshooting-Checkliste und Implementierungsschritte.

Identity Mapping: Wen repräsentiert der Agent?

Wenn ein Agent ein Tool aufruft, müssen Logs und Berechtigungssystem zuerst eine Frage beantworten: Wer hat den Aufruf gestartet, und in wessen Namen wird gehandelt? Diese beiden Entitäten können identisch sein, müssen es aber nicht. Wenn Sie sie vermischen, entstehen Berechtigungsfehler und unbrauchbare Audit-Spuren.

Referenztabelle für Identitätstypen

Felddefinitionen: actor ist die Entität, die den Aufruf startet, etwa Benutzer, Agent, Workflow oder System. Das Log speichert die actor ID. subject ist die Entität, die vertreten wird, also ein Benutzer oder null. Bei direkter Benutzerinteraktion gilt actor=subject. Wenn ein Systemaccount einen Hintergrundjob ausführt, gilt subject=null. delegatedBy markiert die Quelle der Delegation und zeigt, welcher Benutzer diesen Workflow autorisiert hat. tenantId identifiziert den Tenant und dient der Datenisolation in Multi-Tenant-Systemen.

Nach der MCP Authorization Specification müssen MCP servers prüfen, ob ein access token für sie als intended audience ausgestellt wurde. Das audience-Feld des Tokens muss auf die Ressourcenkennung des MCP servers zeigen. Tokens sollten nicht im URI query string stehen, weil URIs in Logs, Browser-Verlauf und Proxy-Caches auftauchen können.

Das OWASP Access Control Cheat Sheet betont deny by default, least privilege und Berechtigungsprüfungen bei jeder Anfrage. Identity Mapping ist der erste Schritt dieser Prüfung: actor, subject und tenantId bestimmen die anschließende Autorisierungsentscheidung.

Tool-Berechtigungen: Was darf der Agent aufrufen?

Tool-Registrierung besteht nicht nur aus name, description und input_schema. Die Tool-Referenz des OpenAI Agents SDK enthält Felder für Berechtigungen und Ausführungskontrolle.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Entscheidungstabelle für Tool-Berechtigungen

Zu den OpenAI Agents SDK Tool-Feldern gehört is_enabled für die Laufzeitsteuerung. Damit lässt sich ein Tool anhand von Benutzerrolle, tenant oder workflow context dynamisch deaktivieren. needs_approval markiert Tools, die eine menschliche Freigabe benötigen. Nach der Freigabe laufen weiterhin tool_input_guardrails. tool_input_guardrails prüfen Eingaben, etwa PII-Erkennung oder Parametergrenzen. tool_output_guardrails prüfen Ausgaben, etwa über Content-Filter.

MCP Security Best Practices empfiehlt bei scope minimization schrittweise Minimalberechtigung: Der initiale Scope sollte nur risikoarme Discovery- oder Leseoperationen enthalten, etwa read:metadata und list:resources. Höhere Rechte werden über präzise scope challenges ergänzt. Wildcard- und full-access scopes sollten vermieden werden.

Das OWASP AI Agent Security Cheat Sheet empfiehlt per-tool permission scoping: unterschiedliche tool sets für unterschiedliche trust levels, explizite Autorisierung für sensible Aktionen und fail closed, wenn eine Berechtigungsprüfung fehlschlägt.

Secret-Isolation: Wie greift der Agent auf Zugangsdaten zu?

Ein Agent sollte keine langfristigen Klartext-API-Keys direkt halten. Das OWASP Secrets Management Cheat Sheet empfiehlt zentrales und standardisiertes Secret Management. Auch das Secret-Management-System selbst sollte Authentication, Authorization, Accounting und Lifecycle unterstützen.

Tabelle für Secret-Zugriffsmuster

Der Secret-Lifecycle besteht aus vier Phasen: creation erzeugt kurzlebige Token statt langfristiger Keys; rotation wechselt Secrets regelmäßig, etwa alle 30 Tage, und ein automatisierter Prozess aktualisiert das Secret und informiert abhängige Systeme; revocation bietet einen Notfall-Widerruf, damit ein geleaktes Secret sofort deaktiviert werden kann; expiration setzt ein Ablaufdatum, nach dem das Secret automatisch ungültig wird.

MCP Security Best Practices bezeichnet token passthrough ausdrücklich als Anti-Pattern: Wenn der OAuth token eines Benutzers direkt an den Agenten weitergereicht wird, werden Sicherheitskontrollen umgangen, die audit trail gebrochen und trust boundaries verletzt. Korrekt ist ein delegated token, wenn der Benutzer den Agenten autorisiert: kurzlebig, im Scope begrenzt und mit klarer Audience.

Die Kernprinzipien von OWASP Secrets Management sind centralize, least privilege, automate und auditing. Secret-Zugriff folgt dem Minimalprinzip. Manuelle Pflege erhöht Leck- und Fehlerrisiko; rotation, revocation und expiration gehören zum Lifecycle.

Audit Logs: Wer hat wann was aufgerufen?

Audit Logs müssen rekonstruieren können, „wer in wessen Namen welches Tool aufgerufen, welches Objekt berührt und welches Ergebnis erhalten hat“. Gleichzeitig müssen Parameter und Secrets maskiert werden.

Audit Log Schema

Maskierungsregeln: token, secret, password, email, phone und PII werden nicht protokolliert. Protokolliert werden who/what/when/where/outcome. Beispiele: customer_id=12345 wird zu cust_, email=user@example.com zu e@***.com, token=Bearer xxx zu Bearer ***, password=secret123 wird gar nicht gespeichert.

Laut OWASP Logging Cheat Sheet sollen Sicherheitslogs Untersuchung, Audit und Monitoring unterstützen, aber keine Passwörter, session IDs, access tokens oder sensiblen personenbezogenen Daten speichern. Sie sollen nachvollziehbare Informationen wie who/what/when/where/outcome enthalten.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Die Audit-and-Accountability-Kontrollfamilie in NIST SP 800-53 unterstreicht: Audit Logs sind die letzte Verteidigungslinie eines Berechtigungssystems. Wenn eine Berechtigungsprüfung fehlschlägt, muss der Grund im Log stehen: actor hat keine Berechtigung, subject hat keine target-Berechtigung oder scope reicht nicht aus.

Entscheidungstabelle für Berechtigungsmodelle: Welche Kontrollen gehören zusammen?

Identity Mapping, Tool-Berechtigungen, Secret-Isolation und Audit Logs sind keine unabhängigen Kontrollkästchen. Sie bilden zusammenhängende Einschränkungen. Die folgende Tabelle zeigt Kontrollkombinationen für typische Szenarien.

Das OWASP AI Agent Security Cheat Sheet empfiehlt separate tool sets für unterschiedliche trust levels und explicit authorization für sensible Operationen. Der Kern der Entscheidungstabelle ist die Kombination: Hochrisiko-Szenarien brauchen mehrere Kontrollschichten, nicht eine einzelne Kontrolle, die alles abdecken soll.

Troubleshooting-Checkliste: typische Symptome von Berechtigungsproblemen

Die folgenden Symptome, Ursachen, Prüfungen und Lösungen tauchen bei Agent-Berechtigungen häufig auf.

Implementierungscheckliste: ein Agent-Berechtigungsmodell von 0 aufbauen

Das sind die fünf Kernschritte, um ein Berechtigungsmodell umzusetzen.

Schritt 1: Identity-Mapping-Regeln definieren

Entscheidungspunkte: Brauchen Sie Multi-Tenant-Isolation, also ein tenantId-Feld? Gibt es Hintergrundjobs, also einen service account? Gibt es Automatisierungsworkflows, also delegated tokens?

Pseudocode:

interface IdentityContext {
  actor: string;        // Entität, die den Aufruf startet
  subject: string | null;  // Entität, die vertreten wird
  delegatedBy?: string;  // Delegationsquelle
  tenantId?: string;    // Tenant-Kennung
}

Schritt 2: Tool Permission Matrix entwerfen

Entscheidungspunkte: Brauchen Sie Freigaben, also needs_approval=true? Brauchen Sie dynamische Filterung, also runtime checks über is_enabled? Brauchen Sie Parameterprüfung, also tool_input_guardrails?

Codebeispiel:

interface ToolPermission {
  name: string;
  permission_level: 'read' | 'write' | 'admin';
  required_scope: string[];
  needs_approval: boolean;
  is_enabled: (context: IdentityContext) => boolean;
}

Schritt 3: Secret Vault anbinden

Entscheidungspunkte: Brauchen Sie kurzlebige Credentials, also eine secret reference? Brauchen Sie Notfallwiderruf, also einen Vault, der sofort deaktivieren kann?

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Codebeispiel:

async function getSecret(secretRef: string, context: IdentityContext): Promise<string> {
  // Identität prüfen
  await vault.authenticate(context.actor);
  // Berechtigung prüfen
  await vault.authorize(context.actor, secretRef);
  // Kurzlebigen Token abrufen
  const token = await vault.getToken(secretRef, expiresIn: '15m');
  // Audit erfassen
  await auditLog.record({
    actor: context.actor,
    action: 'get_secret',
    resource: secretRef,
    outcome: 'success'
  });
  return token;
}

Schritt 4: Audit Logs implementieren

Entscheidungspunkte: Brauchen Sie Maskierung, also redaction-Regeln? Brauchen Sie traceId, also Wiederverwendung von trace/runId aus N156?

Codebeispiel:

interface AuditLogEntry {
  traceId: string;
  timestamp: Date;
  actor: string;
  subject: string | null;
  tool: string;
  action: 'read' | 'write' | 'delete';
  resource: string;  // Maskiert
  outcome: 'success' | 'failure' | 'denied';
}

Schritt 5: Berechtigungsgrenzen testen

Entscheidungspunkte: Testen Sie unbefugten Zugriff, etwa Benutzer A greift auf Daten von Benutzer B zu? Testen Sie Token-Lecks, indem Sie nach einem simulierten Secret-Leck den Widerruf auslösen? Testen Sie Audit-Nachvollziehbarkeit, indem Sie die vollständige Aufrufkette über traceId zurückverfolgen?

Testcheckliste: Unbefugter Zugriff (actor=user_A, resource=tenant_B → sollte 403 liefern); Token-Leck-Test (vault.revoke(secretRef) → der Agent sollte keinen neuen Token mehr erhalten); Audit-Trace-Test (vollständige Aufrufkette über traceId abfragen → sollte actor/subject/tool/outcome enthalten).

Nächste Schritte: weiterführende Lektüre

Ein Agent-Berechtigungsmodell berührt Identität, Tools, Secrets und Audit auf mehreren Ebenen. Die folgenden Beiträge passen als nächste Lektüre.

Veröffentlichte Artikel:

• Agent Sandbox Guide: Die Sandbox löst Laufzeitisolation mit Containern und Docker. Dieser Artikel behandelt Berechtigungs- und Secret-Grenzen; beides ergänzt sich.
• Tool Calling in der Praxis: Grundlagen des Tool Calling. Dieser Artikel erweitert sie um Tool-Allowlists, per-tool Permissions und Eingabeprüfung.
• AI Agent Monitoring und Recovery: Grundlagen für Monitoring und Alerts. Dieser Artikel ergänzt Audit-Felder und traceId.