Geringste Rechte: der Käfig um den Agenten
Dr. Aaron Hutzler · 16.08.2026 · 5 Min.

In der Industrie arbeitet ein Roboter in einem Käfig, um Unfälle zu verhindern. Niemand liest das als Misstrauen gegenüber dem Roboter. Beim Programmieren arbeitet ein ganz ohne Käfig. Dann wundern wir uns über Unfälle.
1975 veröffentlichten Jerome Saltzer und Michael Schroeder einen Aufsatz. Er trägt die Computersicherheit fünfzig Jahre später noch. Der Kern: Jedes Programm und jeder Nutzer arbeitet mit der kleinstmöglichen Menge an Rechten. Die eigene Aufgabe setzt das Maß, nicht mehr [1]. Geschrieben für Betriebssysteme und geteilte Großrechner. Er liest sich heute wie für Code-Agenten geschrieben.
1. Was zu viele Rechte wirklich anrichten
Eine Studie aus dem Jahr 2026 sammelte 42.447 Agenten-Fertigkeiten aus zwei großen Marktplätzen. Sie prüfte 31.132 davon im Detail. 26,1 % trugen mindestens eine ausnutzbare Schwachstelle [2]. Der schärfste Befund war keine Zahl, sondern ein einzelner Fall. Eine Fertigkeit hieß nur „GIF-Ersteller". Nutzer gaben sie genau mit dieser Beschreibung frei. Im Auslösefall lud sie still eine Familie von Schadsoftware nach und führte sie aus [2]. Freigegeben hatte das niemand. Freigegeben wurde ein GIF-Werkzeug. Die Rechte kamen ungefragt mit.
2. Der Mechanismus dahinter
2023 bekam dieser Mechanismus einen Namen: indirekte Injection [3]. Genau deshalb zählen geringste Rechte gerade bei Agenten. Ein Agent liest eine Webseite, ein Ticket, eine Datei, eine Code-Änderung. Der Agent kann Daten und Anweisungen nicht immer unterscheiden. Beides kommt als derselbe Text an. Eine bösartige Anweisung versteckt sich im Inhalt. Der Agent liest ihn. Sie braucht nicht seine Zustimmung. Nur seine Rechte. Ein Agent mit engen Rechten lässt sich täuschen und richtet trotzdem wenig an. Ein Agent mit weiten Rechten macht aus demselben Trick einen echten Vorfall.
3. Kein Gedankenexperiment
2025 erlaubte eine Schwachstelle mit dem Schweregrad 9,6 von 10 den Diebstahl von privatem , API-Schlüsseln und Cloud-Zugangsdaten aus GitHub Copilot Chat. Dafür musste kein Schadcode laufen [6]. Die Angreifer versteckten ihre Anweisung in einer Kommentarsyntax. Diese Syntax zeigt die Oberfläche von GitHub nie an. Ein menschlicher Prüfer sah einen gewöhnlichen . Copilot las den rohen Text darunter und führte die versteckte Anweisung trotzdem aus. Für den Abtransport kodierte es jedes Zeichen als Bildanfrage. Diese Anfragen liefen über den eigenen, vertrauenswürdigen Bildproxy von GitHub [6]. Jeder Schritt dieser Kette ist der Mechanismus von oben, gerichtet auf ein weit verbreitetes Werkzeug. Millionen Menschen setzen es schon heute mit weitem Zugriff auf ihren eigenen Code ein.
4. Ein eigener Fall
Wir haben das nicht nur gelesen. Wir haben unseren eigenen Fall gefunden. Eine Regel sollte den Agenten daran hindern, seine eigenen Grenzen zu verschieben. Bestimmte Änderungen brauchten eine zweite Prüfung, ohne Ausnahme für den Agenten. Die Regel hat nie gegriffen. Die Sitzung des Agenten trug eine Identität mit weitreichenden Verwaltungsrechten. Genau diese Identität stand als einzige Ausnahme in der Regel. Wochenlang wirkte die Kontrolle intakt. Getestet gegen den Agenten selbst wurde die Kontrolle nie [5].
5. Was Spec Coding daraus zieht
Geringste Rechte ist keine Checkliste, sondern eine Haltung. Diese Haltung durchzieht jede Ebene des Agentenbaus:
- Jeder gelesene Text bleibt Daten. Er wird nie zum Befehl. Die strukturelle Trennung von Anweisung und Inhalt ist die direkte Antwort auf indirekte Prompt Injection. Kein Text bekommt automatisch Befehlsrang. Ankommen in der Eingabe reicht nicht [3].
- Jedes Werkzeug und jeden auf die Aufgabe zuschneiden, nicht auf eine Rolle. Ein Schlüssel für alles ist bequem für den Agenten. Er ist genauso bequem für einen Angreifer.
- Die dauerhafte Prüfung in Code legen, nicht in das Urteil des Modells. Eine Vorbedingung im Code lässt sich nicht überreden. Eine Bitte an den Agenten schon.
- Vor allem, was den Käfig verlässt, eine menschliche Entscheidung verlangen. Veröffentlichen, löschen, ausgeben, versenden: Genau an der Grenze zwischen eingehegt und unumkehrbar gehört ein Mensch hin. Ein Schweißroboter in der Fertigungshalle arbeitet aus demselben Grund in einer eingezäunten Zelle. Er reicht nur über den Zaun hinaus. Ein Mensch öffnet dafür das verriegelte Tor.
- Prüfen, was eine Fertigkeit wirklich anfasst, nicht was ihre Beschreibung behauptet. Feingranulare Analyse hält den erklärten Zweck gegen die tatsächliche Reichweite. In einem gemessenen System sanken ausgelöste Rechte-Überschreitungen dadurch um 88,56 % gegenüber dem ungesicherten Lauf. Legitime Aufgaben liefen weiter [4]. Eine kurze Beschreibung ist keine Rechteerklärung.
6. Eine ehrliche Grenze
Ein Schweißroboter arbeitet in einer eingezäunten Zelle. Niemand liest den Zaun als Vorwurf. Er steht dort aus einem einfachen Grund: Eine Maschine dieser Größe und Geschwindigkeit gehört genau dorthin. Nichts davon macht einen Agenten vertrauenswürdig. Es macht nur den Schaden klein. Das Vertrauen stellt sich immer wieder als falsch heraus. Genau das zeigt die Forschung immer wieder. Ein eingehegter Agent kann trotzdem scheitern. Er scheitert nur in einem kleineren Raum. Ein kleinerer Raum ist kein moralischer Sieg, sondern ein technischer Sieg. Genau diesen Sieg soll geringste Rechte auch nie mehr versprechen.
7. Fazit: die Größe des Raums
Gib einem Agenten jedes Recht deines Systems. Du hast damit alles beschrieben, was schiefgehen könnte. Gib ihm nur die Rechte der heutigen Aufgabe. Du hast eine Obergrenze für den Schaden gesetzt.
Vertrauen hält einen Agenten nicht sicher. Die Größe seines Zugriffs tut es.
8. Quellen
[1] J. H. Saltzer und M. D. Schroeder, „The Protection of Information in Computer Systems", Proceedings of the IEEE, Bd. 63, Nr. 9, 1975, S. 1278 bis 1308.
[2] Y. Liu, W. Wang, R. Feng, Y. Zhang, G. Xu, G. Deng, Y. Li und L. Zhang, „Agent Skills in the Wild: An Empirical Study of Security Vulnerabilities at Scale", arXiv:2601.10338, 2026.
[3] K. Greshake, S. Abdelnabi, S. Mishra, C. Endres, T. Holz und M. Fritz, „Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection", Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security (AISec), 2023, arXiv:2302.12173.
[4] J. Wu, Y. Nan, Y. Lin, H. Wang, Y. Xiao, S. Wang und Z. Zheng, „SkillScope: Toward Fine-Grained Least-Privilege Enforcement for Agent Skills", arXiv:2605.05868, 2026.
[5] Betteryields, „Ein eigener Fall", interne Vorfallstudie, security-gates-field-study, 2026-08-01, Befund F5. Eine Regel sollte den Agenten am eigenen Grenzen-Verschieben hindern. Sie hat nie gegriffen. Die Sitzung des Agenten trug eine bestimmte Identität. Genau diese Identität stand als einzige Ausnahme in der Regel.
[6] O. Mayraz, „CamoLeak: Critical GitHub Copilot Vulnerability Leaks Private Source Code", Legit Security, 8. Okt. 2025, CVE-2025-59145
Betteryields
Setzen Sie Qualitäts-Gates in Ihren Build, die ein Agent nicht fälschen kann
