Berechtigungen für AI-Agenten benötigen deterministische Durchsetzung

Berechtigungen für AI-Agenten sollten Fehler eindämmen, selbst wenn das Modell die falsche Entscheidung trifft. Das Design für den Produktionseinsatz ist unkompliziert: Geben Sie jedem Lauf eine eng begrenzte Menge an Fähigkeiten, setzen Sie diese außerhalb des Modells durch, reservieren Sie menschliche Genehmigungen für folgenschwere Aktionen und zeichnen Sie genügend Belege auf, um zu überprüfen, was geschehen ist.

Zielgruppe: Fortgeschrittene Praktiker, die tool-nutzende Agenten, Coding-Agenten oder MCP-Server entwickeln.

Diese Antwort ist wichtig, weil eine Aufforderung wie „vor dem Löschen fragen“ eine Richtlinie, aber keine Grenze der Zugriffskontrolle ist. Ein Modell kann sie falsch verstehen, eine eingeschleuste Anweisung kann mit ihr konkurrieren, und ein Tool kann sich anders verhalten als in seiner Beschreibung. Die Autorisierung muss alle drei Fehlerfälle überstehen.

Was Berechtigungen für AI-Agenten kontrollieren müssen

Ein Berechtigungssystem für Agenten entscheidet, ob ein bestimmter Aufrufer unter den aktuellen Bedingungen eine bestimmte Aktion auf einer bestimmten Ressource ausführen darf. „Der Agent darf GitHub verwenden“ ist zu weit gefasst. Eine nützliche Entscheidung umfasst mindestens:

Die Berechtigungsprüfung gehört an die Tool- oder Servicegrenze. Das Modell darf eine Aktion vorschlagen und begründen. Es sollte nicht selbst entscheiden, ob sein eigener Vorschlag autorisiert ist.

Die Trennung dieser Rollen sorgt außerdem dafür, dass die Geheimnisisolierung tatsächlich belastbar bleibt. Ein Credential-Broker kann einen API-Schlüssel vor dem Modell verbergen und dennoch jede Operation offenlegen, die dieser Schlüssel erlaubt. Der Broker schützt das Geheimnis; eine aktionsbezogene Richtlinie schützt die Ressource.

Was die neueste Forschung zu Berechtigungen gemessen hat

Ein Preprint vom Juli 2026, *How Agents Ask for Permission*, untersuchte 21 Berechtigungssysteme und Vorschläge für Agenten, die zwischen 2024 und 2026 veröffentlicht oder bereitgestellt wurden. Die Autoren analysierten außerdem Ende Mai und Anfang Juni fünf kommerzielle Agenten in isolierten Umgebungen.

Ihre Taxonomie zeigt einen Zielkonflikt zwischen drei technischen Anforderungen:

Diese Zahlen beschreiben die Stichprobe der Autoren, nicht den gesamten Markt. Die Untersuchung verwendete Snowball Sampling, bezog Preprints und kommerzielle Produkte ein und konnte interne Abläufe von Closed-Source-Systemen nicht prüfen. Das Paper ist dennoch nützlich, weil es die Berechtigungsschnittstelle von der Richtlinie und dem Durchsetzungsmechanismus trennt. Ein ausgefeiltes Genehmigungsdialogfeld kann eine unklare Richtlinie oder eine nicht durchgesetzte Entscheidung nicht ausgleichen.

Kommerzielle Tools spiegeln diese Trennung bereits teilweise wider. Claude Code dokumentiert Regeln zum Erlauben, Nachfragen und Ablehnen, während die Sandbox-Dokumentation Grenzen auf Betriebssystemebene für Dateisystem und Netzwerk beschreibt. Die Sicherheitshinweise zu OpenAI Codex behandeln die Sandbox ebenfalls als technische Grenze und die Genehmigungsrichtlinie als den Punkt, an dem ein Benutzer gefragt werden kann. Dies sind produktspezifische Kontrollen und kein Beleg dafür, dass jede Bereitstellung sie sicher konfiguriert.

Genehmigungsmüdigkeit ist ein Routing-Problem

Genehmigungsaufforderungen sind nützlich, wenn der Benutzer eine echte Entscheidung treffen muss. Sie scheitern, wenn jeder routinemäßige Befehl gleich dringend aussieht.

Wiederholte Aufforderungen mit geringem Risiko bringen Menschen dazu, sie einfach durchzuklicken. Anthropic berichtete über eine Reduzierung der Berechtigungsaufforderungen um 84 % nach der internen Einführung einer Sandbox. Dabei handelt es sich jedoch um ein vom Anbieter gemeldetes Betriebsergebnis und nicht um einen unabhängigen Benchmark. Die dauerhafte Lehre ist enger gefasst: Vorab genehmigte Arbeit innerhalb einer durchgesetzten Grenze kann Unterbrechungen reduzieren, ohne dem Agenten globalen Zugriff zu geben.

Leiten Sie Aktionen in vier Ergebnisse:

Das Risiko sollte anhand der Aktion und ihres Schadensradius berechnet werden, nicht anhand des Vertrauens des Modells. Hohes Vertrauen macht eine irreversible Aktion nicht sicherer.

Eine Berechtigungsarchitektur mit fünf Ebenen

Die kleinste glaubwürdige Architektur umfasst fünf klar getrennte Ebenen. Wenn sie zusammengelegt werden, werden Audits schwieriger und Fail-Open-Pfade entstehen.

*Das Modell schlägt eine Aktion vor. Richtlinie, Durchsetzung, Ausführung und Belege bleiben getrennt.*

1. Die vorgeschlagene Aktion normalisieren

Wandeln Sie einen vom Modell erzeugten Tool-Aufruf vor der Autorisierung in eine typisierte Anfrage um:

{ "actor": "agent-run-7f3", "on_behalf_of": "user-42", "action": "blog.publish", "resource": "post:ai-agent-permissions", "constraints": { "environment": "production", "language": "en" } }

Dies ist ein beispielhafter Vertrag und kein Standard. Entscheidend ist, dass die Autorisierung ein stabiles Objekt statt einer frei formulierten Begründung auswertet.

2. Die Richtlinie außerhalb des Modells auswerten

Geben Sie eine deterministische Entscheidung zurück: `allow`, `ask` oder `deny`. Fügen Sie die Richtlinienregel und den Ablaufzeitpunkt hinzu. Ein Modell kann bei der Klassifizierung einer neuartigen Anfrage helfen, aber diese Klassifizierung sollte nicht allein Zugriff gewähren. Unbekannte Aktionen sollten standardmäßig abgelehnt werden.

3. Die Entscheidung bei der Ausführung durchsetzen

Der Tool-Handler oder nachgelagerte Service muss die Entscheidung erneut überprüfen. Verlassen Sie sich nicht darauf, dass der Agent eine Ablehnung beachtet. Binden Sie die Fähigkeit an die exakte Aktion, Ressource, den Aufrufer und ein kurzes Zeitfenster, damit sie nicht für ein anderes Ziel wiederverwendet werden kann.

Die MCP-Autorisierungsspezifikation wendet dasselbe Prinzip auf Zugriffstoken an: Server müssen prüfen, dass ein Token für die vorgesehene Zielgruppe ausgestellt wurde. Die Sicherheitshinweise von MCP verbieten die Weitergabe von Token ausdrücklich, weil dadurch diese Grenze verletzt werden kann.

4. Über eng begrenzte Tools ausführen

Bevorzugen Sie `publish_draft(post_id)` gegenüber `run_sql(query)` und `send_invoice(invoice_id)` gegenüber `http_request(url, body)`. Eng begrenzte Tools machen Richtlinien verständlicher und verkleinern den Raum unbeabsichtigter Aktionen.

Dasselbe Argument für eine Kontrollschicht erscheint in MCP Developer Workflows: The Real Control Layer: Die Form der Tools, Genehmigungsschranken und wiederholbaren Aktionen bestimmen, was ein Agent sicher tun kann.

5. Einen Beleg aufzeichnen und Widerruf unterstützen

Protokollieren Sie die angeforderte Aktion, die Richtlinienentscheidung, die Identität des Genehmigenden, den Digest der Tool-Eingabe, die Ergebnisklasse und die Nachbedingung. Geheimnisse und sensible Payloads müssen redigiert werden. Ein Benutzer sollte eine dauerhafte Genehmigung widerrufen können, ohne den Agenten neu erstellen zu müssen.

Der Beleg muss zwischen „Tool hat geantwortet“ und „Der beabsichtigte Zustand existiert“ unterscheiden. Ein HTTP-200-Status, ein erfolgreicher SDK-Aufruf oder eine selbstsichere Abschlussnachricht ist keine Nachbedingung.

Behandeln Sie Memory-Schreibvorgänge als privilegierte Aktionen

Dauerhafte Memory-Änderungen beeinflussen künftiges Verhalten. Deshalb benötigen Memory-Schreibvorgänge einen eigenen Berechtigungs- und Validierungspfad.

Das MemGhost-Paper vom Juli 2026 führte WhisperBench ein, einen Benchmark mit 108 Fällen für verdeckte Memory-Injection über E-Mail-Workflows. Die Autoren berichten über eine End-to-End-Angriffserfolgsrate von 87,5 % bei zurückgehaltenen Tests gegen eine OpenClaw-Konfiguration und 71,4 % gegen eine Claude Code SDK-Konfiguration. Außerdem berichten sie über eine Übertragung auf andere Memory-Systeme.

Diese Zahlen belegen keine universelle Kompromittierungsrate. Die Experimente decken bestimmte Modelle, Agentenarchitekturen und einen E-Mail-zentrierten Workflow ab; mehrere Auswertungen verwenden LLM-Judges, und das Paper testet keinen über Wochen andauernden Memory-Verfall. Die praktische Schlussfolgerung bleibt dennoch bestehen: Nicht vertrauenswürdige Inhalte sollten ohne Herkunftsnachweis, Schema-Validierung, Mandantentrennung und eine ausdrückliche Schreibregel nicht zu dauerhaftem Agenten-Memory werden.

Ein Memory-Eintrag sollte Folgendes enthalten:

Berechtigungen müssen Tool-Fehler überstehen

Ein Berechtigungsdesign ist unvollständig, wenn es davon ausgeht, dass Tool-Beschreibungen und Antworten stabil bleiben.

ToolBench-X bewertet Agenten unter Spezifikationsdrift, Aufruffehlern, Ausführungsfehlern, Output-Drift und Konflikten zwischen Quellen. Das Paper berichtet, dass Agenten, die mit fehlerfreien Tools gut abschneiden, unter diesen Gefahren schlechter werden, während gezielte Hinweise zur Fehlerbehebung mehr helfen als einfach zusätzliche Testzeit-Rechenleistung. Dies ist ein Benchmark-Ergebnis und keine Produktionsvorfallrate.

AgentTether untersucht fehlgeschlagene Trajektorien und abgesicherte Laufzeitinterventionen. Bei 261 tau-bench-Aufgaben berichten die Autoren, 69,11 % der zunächst fehlgeschlagenen Qwen-Läufe repariert zu haben, 26,02 Prozentpunkte mehr als bei blindem Wiederholen. Die Ergebnisse variieren je nach Domäne, zusätzliche Bewertungen stützen sich auf ein weiteres Modell, und tau-bench kann nicht jede Produktions-Toolchain abbilden.

Diese Papers stützen zwei Kontrollen:

Ein Retry ist eine neue Ausführungsentscheidung und kein Beweis dafür, dass die vorherige Aktion sicher war.

Ein reproduzierbarer Workflow zum Testen von Berechtigungen

Führen Sie diese Tests durch, bevor Sie autonome Schreibvorgänge aktivieren:

Deterministische Agentenmetriken tauchen zunehmend in Open-Source-Evaluierungstools auf. Das DeepEval-4.1.3-Release vom 12. Juli 2026 fügte eine deterministische `ToolPermissionMetric` und `AgentLoopDetectionMetric` hinzu. Dieses Release ist ein Signal für die Einführung, aber kein Beleg dafür, dass die Metriken jeden Missbrauchsfall abdecken.

Unabhängige Verifizierung ist auch über die Sicherheit hinaus wichtig. Dieser hybride AI-Code-Review-Loop verwendet einen separaten Reviewer und einen echten Build als Beleg. Die umfassendere Lehre für Systeme erscheint erneut in Code Agents After 21.54 Billion Tokens: Modellqualität kann Verifizierung und operative Grenzen nicht ersetzen.

Checkliste für den Produktionseinsatz

OWASP’s AI Agent Security Cheat Sheet kommt zu einer ähnlichen operativen Schlussfolgerung: Wenden Sie das Prinzip der geringsten Rechte an, trennen Sie Entscheidungsfindung von irreversibler Ausführung, validieren Sie externe Eingaben, setzen Sie Schleifenlimits durch und führen Sie strukturierte Aktionsprotokolle.

Was diese Evidenz nicht beweist

Die hier zitierten Papers sind aktuelle Preprints und keine etablierten Standards. Ihre Stichproben, Modelle, Tools und Benchmarks begrenzen jedes numerische Ergebnis. Kommerzielle Dokumentation beschreibt verfügbare Kontrollen, aber nicht, ob eine bestimmte Bereitstellung sie korrekt verwendet. GitHub-Releases und Issue-Berichte zeigen aktiven technischen Druck, aber keine systemweiten Ausfallraten.

Die Architektur ist daher ein Entscheidungsrahmen und keine Zertifizierung. Ihr Wert liegt darin, die Sicherheitsgrenze überprüfbar zu machen: Das Modell schlägt vor; die Richtlinie entscheidet; die Infrastruktur setzt durch; die Tools handeln; unabhängige Belege verifizieren.

Überprüfung der Aussagen

Quellen