Least Privilege für KI-Agenten: Rechte, Konten, Zugangsdaten

Nehmen wir einen KI-Agenten, der in einer Steuerkanzlei Belege vorsortiert. Er braucht einen Ordner, darf unter dem Konto der Partnerin aber alles, was sie darf: jede Mandantenakte, jedes Postfach, vielleicht das Bankportal. Unsere These: Die wirksamste Sicherheitsmaßnahme für Agenten ist unspektakulär. Eigene Konten, minimale Rechte und kurzlebige Zugangsdaten begrenzen den Schaden, gleichgültig, warum der Agent falsch handelt. In der Ausgabe 2026 der OWASP Top 10 für LLM-Anwendungen steht Excessive Agency auf Platz 3, ausdrücklich unabhängig davon, was die Fehlfunktion auslöst. Von den drei Ursachen, zu vielen Funktionen, zu weiten Berechtigungen und zu viel Autonomie, geht es hier um die ersten beiden, die Autonomie behandelt unser Beitrag zur menschlichen Freigabe.

Warum persönliche Konten das Grundproblem sind

Das Prinzip Least Privilege ist alt: nur die Rechte, die die Aufgabe verlangt. Das NIST verankert es in seiner Zero-Trust-Architektur (SP 800-207): Zugriff wird je Sitzung und mit den geringsten nötigen Rechten gewährt, die Anmeldung an einer Ressource öffnet nicht automatisch die nächste. Ein persönliches Konto als Agentenkonto verletzt das dreifach.

• Zu viele Rechte: Der Agent erbt alles, was die Person darf. OWASP beschreibt ein verwandtes Muster: ein Werkzeug für die Dokumente eines Nutzers, das mit einem privilegierten Konto auf die Dateien aller Nutzer zugreift.
• Keine Zurechenbarkeit: Im Protokoll ist nicht zu unterscheiden, ob die Partnerin oder der Agent eine Datei gelöscht hat.
• Kein gezielter Entzug: Wer dem Agenten den Zugang sperrt, sperrt die Person mit.

Eigene Konten und eine Positivliste der Werkzeuge

Die großen Plattformen behandeln Agenten inzwischen als eigene Identitäten. Microsoft Entra Agent ID, Stand Oktober 2026 allgemein verfügbar, sieht je Agentenidentität eine verantwortliche Person oder Gruppe als "Sponsor" vor und empfiehlt eine eigene Identität je Agent, damit sich einer abschalten lässt, ohne andere zu treffen. Google Cloud setzt auf seiner Agentenplattform auf Identitäten je Agent statt geteilter Dienstkonten, AWS vergibt in AgentCore ebenfalls eigene Identitäten.

Für Kanzlei, Praxis oder KMU heißt das: ein eigenes, klar benanntes Konto je Agent, etwa "agent-belege", mit einer verantwortlichen Person. Dazu gehört eine Allowlist der Werkzeuge. OWASP rät, nur anzubieten, was die Aufgabe braucht, und offene Werkzeuge wie Shell-Befehle oder beliebige URL-Abrufe zu meiden.

Rechte nach Aufgabe, Lesen und Schreiben getrennt

Bequem ist, dem Agenten Vollzugriff zu geben und die Grenzen in den Systemprompt zu schreiben. OWASP hält dagegen: Berechtigungen gehören deterministisch durchgesetzt, im Werkzeug, in einer vorgeschalteten Prüfinstanz oder im Zielsystem, nicht vom Modell. Das Beispiel von OWASP: Ein Assistent, der E-Mails zusammenfasst, braucht nur Lesezugriff. Kann sein Werkzeug auch senden, genügt eine präparierte E-Mail, um ihn das Postfach durchsuchen und Inhalte weiterleiten zu lassen. Illustrative Beispiele, wie eng sich typische Aufgaben fassen lassen:

Brauchen Teile eines Ablaufs unterschiedliche Rechte, etwa das Lesen sensibler Daten und den Versand nach außen, empfiehlt OWASP, sie nach Berechtigungskontext zu trennen und jedem Teil nur die nötigen Rechte zu geben.

Zugangsdaten: nicht im Prompt, kurzlebig, widerrufbar

OWASP rät in der Ausgabe 2026, davon auszugehen, dass alles im verborgenen Kontext eines Modells auffindbar ist. Passwörter, API-Schlüssel und Tokens gehören daher nicht in das Kontextfenster, sondern in Systeme, auf die das Modell keinen direkten Zugriff hat. Wie Angreifer Modelle über Inhalte steuern, erklärt unser Beitrag zu Prompt Injection. Die Lösung heißt Secrets-Management: Zugangsdaten liegen in einem Tresor, die ausführende Komponente holt sie bei Bedarf. AWS beschreibt für AgentCore einen solchen Token-Tresor, Microsoft rät in Produktion zu Zertifikaten oder verwalteten Identitäten statt Client-Secrets.

Kurzlebig, weil gestohlene Zugangsdaten dann nur kurz nützen: Der Secrets-Management-Leitfaden von OWASP empfiehlt Ablaufdaten, regelmäßige Rotation und, wo möglich, dynamisch erzeugte Geheimnisse. Google bindet Zugriffstokens von Agentenidentitäten kryptografisch an das Zertifikat des Agenten und lässt für sie keine langlebigen Schlüssel erzeugen.

Widerrufbar heißt: Sie wissen, welche Zugangsdaten ein Agent hat, und können genau diese sperren. Beim Projekt Cline wurde im Februar 2026 nach einer öffentlich gemachten Lücke das falsche npm-Token gelöscht. Das offengelegte blieb aktiv und ermöglichte eine unautorisierte Veröffentlichung, rund acht Stunden lang verfügbar. Weitere Fälle sammelt unser Beitrag zu dokumentierten Vorfällen.

Schleichende Rechteausweitung verhindern

Rechte wachsen leise: OWASP nennt das ersetzte Testwerkzeug, das für den Agenten erreichbar bleibt. Google weist darauf hin, dass die Rechtezuweisungen eines gelöschten Agenten als inaktive Einträge in den Richtlinien stehen bleiben, bis jemand sie entfernt. Ein einfacher Ablauf hält dagegen:

1. Inventar: jeder Agent mit Konto, Werkzeugen, Rechten und verantwortlicher Person.
2. Regelprüfung: Microsoft empfiehlt, dass die Verantwortlichen alle sechs bis zwölf Monate bestätigen, dass der Agent noch gebraucht wird. Ändert sich die Aufgabe, prüfen Sie sofort.
3. Stilllegung: Konto deaktivieren, Rechte entfernen, Zugangsdaten widerrufen und den Widerruf am Zugangsdatum selbst prüfen.

Für Einrichtungen im Anwendungsbereich des NISG 2026 gehört das zu den Pflichten: § 32 Abs. 4 lit. i verlangt seit 1. Oktober 2026 unter anderem Konzepte für die Zugriffskontrolle. Den Rahmen erklärt unser Beitrag zum NISG 2026.

Minimale Rechte brauchen eine Grenze außerhalb des Modells

In AEGIS, dem lokal betriebenen Agentensystem von oQueo, hat das Sprachmodell keine Zugangsdaten und keinen Zugriff auf Werkzeuge, es schlägt Aktionen nur vor. Eine getrennte Prüfinstanz lässt nur Werkzeuge der Positivliste zu, begrenzt jeden Agenten auf eine Höchststufe und erlaubt Internetzugriffe nur auf freigegebene Domains. Was nicht ausdrücklich erlaubt ist, wird abgelehnt (Default-Deny). Die Rechte legen Sie fest, und eine zu großzügige Positivliste bleibt zu großzügig. Mehr dazu unter Sicherheit.