Wem man einem Agenten die Schlüssel gibt // nh labs

Die falsche Frage

Wenn Teams über KI-Agenten reden, dreht sich fast alles um Fähigkeit. Kann er das Feature bauen? Versteht er die Codebasis? Findet er den Bug? Das sind die Fragen, die auf Demos beeindrucken und in Slack-Threads geteilt werden. Es sind auch die falschen Fragen, jedenfalls die harmlosen.

Die Frage, die einem nachts den Schlaf rauben sollte, ist eine andere: Was darf dieser Agent eigentlich tun? Nicht was er kann – was er darf. Denn ein Agent, der Code schreibt, ist ein netter Kollege. Ein Agent, der eine Shell hat, deine Produktions-Zugangsdaten kennt und ins offene Internet telefonieren darf, ist etwas völlig anderes: ein neuartiger privilegierter Akteur, der mit deiner Autorität handelt, in Sekunden, ohne müde zu werden – und der sich von jeder Zeile Text steuern lässt, die in seinen Kontext gerät.

Der Bruch in der Denkweise, den die meisten Teams noch vor sich haben, ist dieser: Ein Agent ist kein Werkzeug, das man benutzt. Er ist ein Handelnder, dem man etwas erlaubt. Und die Disziplin, die darüber entscheidet, ob er ein nützlicher Assistent oder ein selbstverschuldeter Breach wird, ist so alt wie langweilig: Least Privilege. Wem man welche Schlüssel gibt.

Der Confused Deputy: Handeln mit fremder Autorität

Es gibt ein Sicherheitsproblem, das seit den Siebzigern einen Namen hat und das bei Agenten mit voller Wucht zurückkehrt: den Confused Deputy, den verwirrten Stellvertreter. Die Grundfigur ist einfach. Ein Akteur besitzt eine Berechtigung. Ein anderer, der diese Berechtigung nicht hat, bringt ihn dazu, sie in seinem Sinne einzusetzen. Der Stellvertreter handelt mit seiner eigenen, legitimen Autorität – nur eben auf fremde Anweisung hin, und ohne zu merken, dass er benutzt wird.

Ein Agent ist der perfekte Stellvertreter. Er hat deine Zugangsdaten. Er hat Werkzeuge. Und er verarbeitet Text aus Quellen, die nicht du bist: eine GitHub-Issue, die er lesen soll, die Antwort einer API, der Inhalt einer Webseite, ein Kommentar in einer Datei, ein Ticket im Support-System. Jede dieser Quellen kann eine Anweisung enthalten. Und der Agent kann strukturell schlecht unterscheiden zwischen „das hat mein Betreiber mir aufgetragen" und „das stand in den Daten, die ich verarbeiten sollte".

Das grenzt an Prompt Injection, ist aber ein weitergehendes Problem. Prompt Injection beschreibt die bösartige Eingabe – den Trick, mit dem jemand die Anweisung in den Kontext schmuggelt. Der Confused Deputy beschreibt, warum diese Eingabe überhaupt gefährlich ist: weil der Agent die Autorität und die Werkzeuge besitzt, sie in Schaden zu übersetzen. Man kann die Injection nie vollständig verhindern – aber man kann dafür sorgen, dass der Stellvertreter, selbst wenn er verwirrt wird, kaum Schaden anrichten kann. Genau darum geht es beim Berechtigungsdesign. Nicht darum, den Agenten davon abzuhalten, verwirrt zu werden. Darum, den Sprengradius seiner Verwirrung klein zu halten.

Least Privilege für Agenten

Das Prinzip ist alt und gilt für Menschen wie für Dienste: Gib jedem genau die Rechte, die er für seine Aufgabe braucht – und keins mehr. Bei Agenten wird aus dem soliden Ratschlag eine harte Notwendigkeit, weil ein Agent schneller, breiter und autonomer handelt als jeder menschliche Nutzer, dem man denselben Schlüssel gäbe.

Konkret heißt das ein paar Dinge, die man nicht verhandeln sollte:

Read-only als Default. Die überwiegende Mehrheit dessen, was ein Agent tut – lesen, analysieren, Vorschläge machen –, braucht keinen Schreibzugriff. Der Default ist nicht „darf alles, außer wir verbieten es", sondern „darf lesen, alles Weitere ist eine bewusste Entscheidung".
Gescopte Tokens statt God-Mode-Keys. Ein API-Token, das nur ein Repository sehen darf, ist eine andere Welt als ein Personal Access Token mit Org-weitem Admin-Recht. Wenn der Agent nur den Kalender lesen soll, gib ihm ein Token für „Kalender lesen" – nicht den Schlüssel, der zufällig auch Kalender kann und nebenbei die Mailbox löschen darf.
Keine stehenden Prod-Credentials. Die gefährlichste Kombination ist ein Agent mit dauerhaftem, unbeaufsichtigtem Zugang zur Produktion. Zugangsdaten, die permanent im Kontext oder in der Umgebung eines Agenten liegen, sind Zugangsdaten, die permanent exfiltrierbar sind.
Ephemere Per-Task-Credentials. Der richtige Modus ist ein Schlüssel, der für diese eine Aufgabe ausgestellt wird, minimal gescopt, mit kurzer Lebensdauer, und der danach wertlos ist. Ein geleaktes Token, das in fünf Minuten abläuft und nur ein Repo lesen konnte, ist ein Ärgernis. Ein geleakter God-Mode-Key ist ein Vorfall mit Meldepflicht.

Dasselbe gilt für die Werkzeugebene. Wenn ein Agent über MCP oder eine ähnliche Tool-Schnittstelle mit der Welt spricht, ist jedes freigeschaltete Tool ein Recht. Ein MCP-Server, der „Datenbank abfragen" anbietet, sollte nicht klammheimlich auch „Datenbank-Tabelle löschen" können, nur weil beides zufällig im selben Server steckt. Die Berechtigung gehört auf die Ebene der einzelnen Aktion, nicht auf die Ebene „Agent redet mit Datenbank, ja oder nein".

Der Sprengradius einer Shell

Es gibt eine Berechtigung, die alle anderen in den Schatten stellt, und sie klingt so harmlos: bash. Sobald ein Agent eine Shell ausführen darf, hat er nicht ein Werkzeug – er hat alle Werkzeuge. Eine Shell ist kein Feature, sie ist ein Universalschlüssel. Was der Agent damit anrichten kann, bemisst sich nicht mehr an dem, was du ihm gegeben hast, sondern an dem, was auf der Maschine erreichbar ist.

Drei Beispiele, die keine Science-Fiction sind, sondern schlicht das, was eine Shell tut:

rm. Ein verwirrter oder schlecht instruierter Agent, der ein Verzeichnis „aufräumen" soll, kann ein rm -rf auf den falschen Pfad absetzen. Kein böser Wille nötig – ein plausibel klingender Pfad, eine falsche Annahme über das Arbeitsverzeichnis, und die Arbeit von Stunden ist weg.
curl zur Exfiltration. Das ist der Fall, der wehtut. Ein Agent, der lesen und ins Netz telefonieren darf, kann alles, was er liest, an einen fremden Host schicken. Eine .env-Datei, ein SSH-Key, eine Kundendatenbank – ein einziges curl -X POST an eine Adresse, die in einer manipulierten Issue stand, und die Daten sind draußen. Der Agent hat nichts „gehackt". Er hat gelesen und gesendet, beides durfte er.
git push. Ein Agent mit Schreibzugriff aufs Remote kann Code in Zweige schieben, die deployt werden. Aus „schreib mir den Fix" wird, eine Confused-Deputy-Kette später, „schieb mir das in main" – und wenn die Pipeline auf Push deployt, ist der Weg von der manipulierten Anweisung bis in die Produktion kürzer, als irgendjemandem lieb ist.

Die Lehre ist nicht „nie eine Shell". Die Lehre ist, dass bash die Berechtigung mit dem mit Abstand größten Sprengradius ist und entsprechend behandelt gehört: nicht als Häkchen, das man beim Setup einmal setzt, sondern als bewusste, begrenzte, überwachte Entscheidung.

Menschen an den Türen, die sich nicht schließen lassen

Nicht jede Aktion ist gleich. Eine Datei zu lesen ist reversibel und folgenlos. Eine Datenbank zu löschen ist keins von beidem. Die entscheidende Unterscheidung ist nicht „wichtig" gegen „unwichtig", sondern umkehrbar gegen unumkehrbar – und für alles Unumkehrbare gehört ein Mensch an die Tür.

Vier Klassen von Aktionen verdienen ein hartes menschliches Gate, egal wie zuverlässig der Agent sonst wirkt:

Deploys. Alles, was Code in die Produktion befördert. Der Schritt von „getestet" zu „live" ist der Moment, an dem ein Fehler aufhört, deiner zu sein, und anfängt, der deiner Nutzer zu werden.
Löschen. Ressourcen, Daten, Infrastruktur. Das Kippen einer Tabelle, das Zurücknehmen einer Migration, das Terminieren einer Instanz – alles, was ein undo nicht kennt.
Geld ausgeben. Ressourcen provisionieren, ein Abo abschließen, eine Zahlung auslösen. Ein Agent, der ungebremst Infrastruktur hochfahren darf, ist auch ein Agent, der eine Rechnung über tausende Euro produzieren kann.
Nach außen senden. E-Mails, Nachrichten, API-Calls an Dritte, alles, was deine Grenze verlässt und in fremden Systemen landet. Eine versendete Mail holt man nicht zurück, und eine an den falschen Verteiler ist ein eigener kleiner Breach.

Human-in-the-Loop heißt hier nicht „ein Mensch guckt am Ende drüber". Es heißt: Der Agent bereitet die Aktion vor, legt sie hin, und die letzte, auslösende Bewegung macht eine Person, die versteht, was passiert, wenn sie klickt. Für destruktive Operationen ist die Bestätigung kein Ritual, sondern die eigentliche Sicherung. Alles, was man nach dem Klick bereut, hätte man vor dem Klick sehen müssen.

Sandboxing, Egress und die Ratsche

Zwei technische Leitplanken machen den Unterschied zwischen einem Fehler und einer Katastrophe. Die erste ist Sandboxing: Der Agent läuft in einer isolierten Umgebung – ein Container, eine Wegwerf-VM, ein abgeschottetes Verzeichnis –, in der selbst ein entfesseltes rm nur zerstört, was ohnehin ephemer ist. Die Maschine, auf der der Agent tobt, sollte niemals die Maschine sein, auf der etwas Wertvolles unwiederbringlich liegt.

Die zweite, und die wird chronisch unterschätzt, ist Egress-Kontrolle. Der Confused Deputy wird erst durch das Senden gefährlich. Ein Agent, der lesen darf, aber physisch nicht nach draußen telefonieren kann – weil sein Netzwerk nur eine Handvoll erlaubter Ziele erreicht –, kann gar nicht exfiltrieren, egal wie geschickt man ihn manipuliert. Die meisten Setups regeln peinlich genau, was der Agent tun darf, und lassen den Netzwerkausgang sperrangelweit offen. Dabei ist der Egress-Filter oft die letzte Wand, die zwischen einer verwirrten Anweisung und deinen Daten in fremder Hand steht.

Und dann ist da die Dynamik, die all das langsam wieder aushöhlt: die Ratsche. Sie klingt vernünftig und ist tückisch. Der Agent bekommt eng gescopte Rechte. Es funktioniert. Ermutigt gibt man ihm mehr Zugriff, damit er mehr erledigen kann. Es funktioniert wieder. Man gibt ihm noch mehr. Jeder einzelne Schritt ist durch echten Nutzen gerechtfertigt, und keiner fühlt sich nach einer Grenzüberschreitung an. Die Rechte wandern immer nur in eine Richtung – nach oben, nie zurück –, und irgendwann steht dort ein Agent mit stehenden Prod-Credentials und offener Shell, und niemand kann mehr genau sagen, welche Entscheidung ihn dorthin gebracht hat. „Es hat funktioniert, also gaben wir ihm mehr Zugriff" ist der Satz, mit dem sich Least Privilege still zu Tode privilegiert. Rechte gehören regelmäßig zurückgedreht, nicht nur vergeben.

Die ehrliche Gegenseite: Ein gelähmter Agent ist auch keine Lösung

Jetzt die Kehrseite, sonst zieht man die Lehre zu weit. Man kann einen Agenten so hart abriegeln, dass er nutzlos wird – und ein nutzloser Agent ist kein sicherer Agent, sondern gar keiner. Ein Assistent, der für jeden einzelnen Datei-Lesevorgang um Erlaubnis fragen muss, ist schlechter als kein Assistent: Er kostet Aufmerksamkeit, liefert nichts, und die Person am anderen Ende lernt in Rekordzeit, die Bestätigungsdialoge blind wegzuklicken. Damit ist die Leitplanke nicht nur nutzlos, sondern schädlich, weil sie das eine trainiert, was man nie trainieren wollte: reflexhaftes Zustimmen.

Das Ziel ist nicht null Fähigkeit. Das Ziel ist, Privileg an Sprengradius anzupassen – dieselbe Kalibrierung, die gutes Code-Review ausmacht. Read-only und geringes Risiko? Laufen lassen, ohne zu fragen. Eine Datei im Projektverzeichnis lesen, eine Query gegen eine Replica, eine Analyse schreiben – dafür braucht es kein Gate, und jedes Gate an dieser Stelle ist verschwendete Aufmerksamkeit. Irreversibel, teuer oder nach außen gerichtet? Gaten, jedes Mal. Die Kunst liegt nicht darin, alles zu blockieren, sondern die knappe Ressource menschliche Aufmerksamkeit dorthin zu lenken, wo ein Fehler wirklich wehtut.

Und der Grund, warum Überrestriktion nicht nur ineffizient, sondern gefährlich ist: Sie treibt die Leute dazu, die Leitplanken ganz abzuschalten. Ein Team, das mit einem Agenten kämpft, der bei jedem Schritt bettelt, findet garantiert den globalen Schalter, der alle Bestätigungen deaktiviert – und ab da läuft ein God-Mode-Agent ohne jedes Gate, weil die feinkörnige Variante unerträglich war. Zu viel Sicherheit erzeugt, wie so oft, am Ende weniger davon. Die einzige Sicherung, die hält, ist die, die man auch wirklich anlässt.

Fazit

Die beängstigende Frage bei einem Agenten war nie, ob er Code schreiben kann. Das kann er, und er wird es besser können. Die Frage ist, was er tun darf: welche Schlüssel in seinem Kontext liegen, welche Werkzeuge freigeschaltet sind, wie weit sein Netzwerk reicht, und was zwischen seiner Absicht und deiner Produktion steht. Ein Agent mit Shell, Zugangsdaten und Internet ist ein privilegierter Akteur, und man behandelt ihn wie einen – nicht wie ein Autocomplete.

Least Privilege ist dafür keine Schikane, sondern die einzige Disziplin, die den Unterschied zwischen einem nützlichen Assistenten und einem selbstverschuldeten Breach zuverlässig hält. Gescopte, ephemere Credentials statt God-Mode-Keys. Read-only als Default. Sandbox und Egress-Filter als Wände, die auch dann halten, wenn der Agent verwirrt wird. Und ein Mensch an jeder Tür, die sich nicht wieder schließen lässt.

Genau so betreiben wir bei NH Labs unsere Agenten. Sie bekommen die Rechte, die ihre Aufgabe braucht, und keins mehr; ihre Zugangsdaten sind gescopt und kurzlebig; sie laufen isoliert, mit kontrolliertem Netzwerkausgang. Und auf allem, was irreversibel oder nach außen gerichtet ist – Deploy, Löschen, Geld, Versand –, steht ein menschliches Gate, das kein Agent umgeht. Nicht, weil wir der Fähigkeit misstrauen, sondern weil wir wissen, dass Fähigkeit ohne begrenzten Sprengradius kein Fortschritt ist, sondern nur ein größeres Risiko mit besserer PR.