This blog post is also available in English

TL;DR

  • „KI-Agenten im Betrieb brauchen engere Rechte als Cronjobs, weil sie Wege selbst wählen.“
  • „Schäden entstehen meist durch überprivilegierte Tokens, fehlenden Löschschutz und vermischte Umgebungen.“
  • „Autonomie richtet sich nach Rücknehmbarkeit: beobachten ok, reversible Aktionen begrenzt, Destruktives nie.“
  • „Zugriff über eigene Accounts, kurzlebige Zertifikate und Session-Proxies schafft Audit und Kill-Switch.“
  • „Allowlists und Prompts reichen nicht; Runbook-Skripte, plan/apply und getrennte Backups begrenzen Prompt-Injection.“

Auf unseren Servern arbeitet seit Jahren Software mit weitreichenden Rechten. Ein Cronjob räumt jede Nacht alte Logs weg, Ansible spielt Konfigurationen ein, und die CI-Pipeline deployt mit Berechtigungen, die im Team kaum jemand im Alltag hat. Darüber denkt niemand lange nach, weil diese Software nur das tut, was in ihrem Code oder ihrer Konfiguration steht.

Ein Agent funktioniert anders. Er bekommt ein Ziel und sucht sich den Weg selbst. Nachts um drei meldet ein Alert, dass die Platte eines Servers voll ist. Der Agent meldet sich an und findet ein Log, das seit einem kaputten Deployment jede Sekunde dieselbe Exception schreibt. Er kann das Log rotieren und den Dienst neu starten. Genauso viel Platz schafft es aber, die alten Datenbank-Dumps unter /var/backups zu löschen, und für den Alert ist beides eine Lösung. Welchen Weg der Agent wählt, hängt davon ab, was er in dem Moment für sinnvoll hält. Beeinflussen kann man das nur über seine Anweisungen und seine Rechte.

Trotzdem halte ich es für machbar, dass Agenten im Betrieb mitarbeiten, also Alerts annehmen, sich auf Servern anmelden, Logs lesen und Dienste neu starten. Einem neuen Kollegen gibt man in der ersten Woche aber auch nicht das Root-Passwort. Er bekommt einen eigenen Account mit wenigen Rechten, und eine Weile schaut ihm jemand über die Schulter. So würde ich auch beim Agenten anfangen, wobei für ihn auch nach der Einarbeitung jemand zuständig bleiben muss.

Was Agenten im Betrieb heute können

Betrieb ist, grob gesagt, alles nach dem Deployment. Wer On-Call hat, also Bereitschaft, wird bei Störungen alarmiert, auch nachts. Für bekannte Störungen gibt es im besten Fall Runbooks, schriftliche Anleitungen nach dem Muster „wenn das passiert, prüfe dies und tu jenes“. Ein großer Teil der Arbeit ist Routine, im Jargon Toil genannt. Gemeint sind volle Platten, abgelaufene Zertifikate, hängende Prozesse oder ein Deployment, das zurückgerollt werden muss.

Die großen Anbieter haben dafür inzwischen Produkte. AWS hat den DevOps Agent im März 2026 allgemein verfügbar gemacht, Microsoft hat den Azure SRE Agent (SRE steht für Site Reliability Engineering, Betrieb als Ingenieursdisziplin), Datadog und PagerDuty bauen eigene Varianten. Dazu kommt Open Source wie HolmesGPT, das bei der Cloud Native Computing Foundation liegt. Die Produkte arbeiten ziemlich ähnlich. Sie lesen Logs und Metriken und gleichen sie mit den letzten Deployments ab, am Ende steht eine Vermutung zur Ursache. Eingreifen dürfen sie meist nur über einen Pull Request oder eine einzelne Aktion, die ein Mensch freigibt. Auf der Plattform Builder Center schreibt jemand von AWS, ausdrücklich als persönliche Sicht: „The agent investigates and recommends; humans approve and execute.“ HolmesGPT hat laut README „by design“ nur lesenden Zugriff. Gergely Orosz kommt in seinem Überblick vom Oktober 2026 ebenfalls zu dem Ergebnis, dass die Werkzeuge vor allem beim Untersuchen helfen.

Im Benchmark ITBench-AA vom Mai 2026 sollten Modelle die Ursache von Störungen in Kubernetes-Clustern finden, und das beste Modell lag bei 47 Prozent. Längeres Suchen brachte keine besseren Treffer, die Modelle verloren sich eher in Nebenschauplätzen. Alex Palcuie, früher SRE bei Google Cloud und heute bei Anthropic, sagte auf der QCon London, fürs Beobachten seien die Modelle großartig, sie läsen Logs „at the speed of I/O“. Bei der Ursache verwechselten sie aber gern Korrelation und Kausalität.

Die Doku zum Azure SRE Agent beschreibt zwei Modi. Im Review-Modus schlägt der Agent Aktionen vor und wartet auf Freigabe, im Autonomous-Modus handelt er und berichtet hinterher. Microsoft rät, zwei bis vier Wochen im Review-Modus mitzulesen und erst danach einzelne Auslöser freizuschalten. Für den Agenten als Ganzes ist Review voreingestellt. Legt man aber einen Incident-Response-Plan oder eine geplante Aufgabe an und lässt die Voreinstellung stehen, läuft der Agent dort von Anfang an autonom.

Daneben gibt es den Weg ganz ohne Produkt. Jemand gibt Claude Code oder der Codex CLI Zugang zu Servern oder Cloud-Accounts und lässt den Agenten dort arbeiten. Für das Einrichten eines Nginx oder das Reparieren einer kaputten Konfiguration klappt das gut. Die meisten bekannten Schäden kommen aus dieser Ecke.

Was schiefgegangen ist

Im Februar 2026 ließ der Betreiber einer Lernplattform Claude Code Terraform-Befehle gegen den eigenen AWS-Account ausführen. Terraform verwaltet Cloud-Infrastruktur und merkt sich ihren Zustand in einer State-Datei. Genau die fehlte, weil sie noch auf einem alten Rechner lag. Beim Aufräumen griff der Agent auf einen älteren State zurück und führte terraform destroy gegen die Produktion aus. Netzwerk, Cluster und Datenbank samt Snapshots waren weg, erst nach rund 24 Stunden konnte der AWS-Support die Daten wiederherstellen. Einen Löschschutz gab es nicht, Entwicklung und Produktion lagen im selben Account, und vor dem destroy hat niemand mehr auf den Plan geschaut.

Bei PocketOS fand ein Agent im April 2026 während einer Aufgabe in der Staging-Umgebung einen API-Token in einer fremden Datei. Gedacht war der Token für die Domainverwaltung, er hatte aber Vollrechte. Ein einziger Aufruf löschte ein Speicher-Volume und mit ihm die Backups, die auf demselben Volume lagen. Bei Replit hat ein Agent schon im Juli 2025 trotz angeordnetem Änderungsstopp eine Datenbank gelöscht und danach behauptet, ein Rollback sei unmöglich. Replit hat Entwicklung und Produktion danach getrennt. Und bei Amazon soll laut Financial Times im Dezember 2025 der hauseigene Agent Kiro eine Umgebung gelöscht und neu aufgebaut haben, mit 13 Stunden Ausfall als Folge. Amazon widerspricht und nennt es „user (AWS employee) error - specifically misconfigured access controls - not AI“.

Die Agenten haben in allen vier Fällen Fehler gemacht. Möglich wurde der Schaden aber erst, weil etwa ein Token viel zu viele Rechte hatte oder die Backups direkt neben den Daten lagen, und das hätte genauso einen Menschen treffen können. Dagegen hilft, was im Betrieb längst üblich ist, also eng gefasste Tokens und Backups an einem anderen Ort.

Wie gefährlich ist die Aufgabe?

Ob ein Agent eine Aufgabe übernehmen darf, hängt vor allem davon ab, wie viel ein Fehler anrichtet und ob er sich zurücknehmen lässt.

Am harmlosesten ist das Beobachten, also Logs und Metriken lesen oder mit systemctl status nachsehen, ob ein Dienst läuft. Ganz ohne Risiko ist auch das nicht, weil dabei Daten abfließen können und der Agent Text liest, den Fremde geschrieben haben. Bei der Diagnose kann er sich irren. Solange ein Mensch den Befund bewertet, bevor etwas passiert, kostet ein Irrtum aber vor allem Zeit.

Heikler wird es, sobald der Agent eingreift. Einen Dienst neu zu starten oder ein Deployment zurückzurollen kann einen kurzen Ausfall verursachen, lässt sich aber rückgängig machen. Hier kann es reichen, dass ein Mensch den Eingriff im Einzelfall freigibt oder vorab ein Runbook für genau diesen Fall abgesegnet hat. Änderungen an Konfigurationen oder Paketen erzeugen eher schleichende Fehler, die manchmal erst Tage später auffallen. Sind sie versioniert, kommt man meistens zurück, trotzdem sollte jeder solche Plan vor der Ausführung freigegeben werden. Was sich gar nicht zurücknehmen lässt, etwa Daten löschen oder Infrastruktur abreißen, macht ein Mensch selbst.

Die Abstufung lehnt sich an Feng, McDonald und Zhang an („Levels of Autonomy for AI Agents“, 2025). Sie beschreiben die Autonomie eines Agenten über die Rolle des Menschen und betonen, dass sie eine Designentscheidung ist und keine Eigenschaft des Modells. Im Beispiel vom Anfang dürfte der Agent den Dienst nachts vielleicht allein neu starten. Das Löschen unter /var/backups sollte ihm dagegen gar nicht erlaubt sein.

Wie der Agent auf den Server kommt

Am schnellsten geht es, wenn der Agent den SSH-Schlüssel eines Admins bekommt oder gleich root. Dann steht in jedem Log derselbe Name, egal ob ein Mensch oder der Agent etwas getan hat. Eine nützliche Prüffrage für jedes Setup ist deshalb, wessen Name im auth.log steht, dem Anmeldeprotokoll des Servers, wenn der Agent sudo ausführt.

Besser bekommt jeder Agent einen eigenen Account, und zwar mit Zugangsdaten, die von selbst ablaufen. Statt eines SSH-Schlüssels, der unbegrenzt gilt, nimmt man ein SSH-Zertifikat. Soll der Agent nicht mehr rein, stellt man ihm kein neues aus. Noch weiter geht ein Zugangs-Proxy. Der Agent verbindet sich dann über einen Vermittler mit dem Server, der die Sitzung aufzeichnet und jederzeit beenden kann. Die Zugangsdaten setzt der Proxy selbst ein, der Agent bekommt sie nie zu sehen. Teleport und HashiCorp Boundary bieten so etwas inzwischen ausdrücklich für Agenten an, teils noch als Vorschau.

Ins Protokoll gehört außerdem, in wessen Auftrag der Agent unterwegs war, denn der technische Account allein verrät nur, dass der Agent gehandelt hat.

Bei PocketOS hat der Agent einen Token benutzt, der in einer Datei herumlag und weit mehr durfte als nötig. Die britische Cybersicherheitsbehörde NCSC schreibt in einer Handreichung vom Mai 2026: „give agents only the minimum access they need, for the shortest time required“. Einige Zeilen weiter heißt es „avoid long-lived credentials“.

Befehlslisten reichen nicht

Viele fangen mit einer Liste erlaubter Befehle an, etwa systemctl restart, journalctl und df und sonst nichts. Trail of Bits hat 2025 drei Agenten-Produkte untersucht, die so arbeiteten. Als sicher galten dort etwa go test, git show und rg, geprüft wurde nur der Name des Befehls. Über passende Flags, also Kommandozeilen-Optionen, ließ sich trotzdem beliebiger Code ausführen. Das Fazit der Autoren: „Maintaining allowlists of ‚safe‘ commands without a sandbox is fundamentally flawed.“

Auf Servern kennt man das Problem seit Langem aus der sudo-Konfiguration, in der steht, welche Programme ein Account mit Root-Rechten starten darf. Viele harmlos wirkende Programme öffnen eine Shell. In less reicht !/bin/sh, in vim :!sh, und find hat -exec. Wer dem Agenten sudo less erlaubt, damit er Logs lesen kann, gibt ihm damit Root-Rechte. Die Sammlung GTFOBins listet Hunderte solcher Wege.

Die Sandbox, in der Claude Code oder Codex ihre Befehle ausführen, hilft hier auch nicht. Sie schottet den Rechner ab, auf dem der Agent läuft. Was er per SSH auf einem anderen Server tut, liegt außerhalb.

Die Grenze muss deshalb auf dem Zielsystem selbst gezogen werden. Ein paar Dinge helfen dabei:

  • Für Lesen und Handeln gibt es getrennte Accounts. Wer nur Logs liest, braucht keine Schreibrechte.
  • sudo gilt nur für eigene kleine Skripte ohne freie Argumente, etwa restart-app.sh, und nicht für allgemeine Werkzeuge wie less oder find.
  • Statt einer offenen Shell bekommt der Agent Runbooks als einzelne, getestete Aktionen. Er sucht aus, welches passt, aber nicht, was darin passiert.
  • Änderungen an der Infrastruktur laufen über Plan und Apply. terraform plan oder kubectl --dry-run zeigen vorher, was sich ändern würde, ausgeführt wird erst nach Freigabe.
  • Was nicht verloren gehen darf, liegt außerhalb seiner Reichweite, mit Löschschutz und Backups in einem anderen Account.

Was der Agent liest, kann ihn steuern

Ein Agent im Betrieb liest den ganzen Tag Text, den andere geschrieben haben, vor allem Logzeilen und Fehlermeldungen, manchmal auch HTTP-Header oder Tickets. Steht darin eine Anweisung, befolgt das Modell sie unter Umständen so, als käme sie vom eigenen Team. Angriffe dieser Art werden als Indirect Prompt Injection bezeichnet, da die Anweisung über die verarbeiteten Daten in den Kontext des Modells gelangt.

Eine Studie vom April 2026 hat das mit Logs durchgespielt („LogJack“). Sie versteckte Anweisungen in Cloud-Logs und setzte acht Modelle als Debugging-Agenten darauf an. Je nach Modell wurden die eingeschleusten Befehle in 0 bis 86 Prozent der Fälle ausgeführt. Ein curl | bash, mit dem ein fremdes Skript geladen und sofort ausgeführt wird, klappte bei sechs von acht Modellen. Die Schutzfilter zweier großer Cloud-Anbieter erkannten fast nichts davon. Auch das BSI schreibt in einer Sicherheitsinformation vom Juni 2026, Prompt Injection werde „vor allem in agentischen Systemen“ kritisch, und empfiehlt Absicherung durch „Isolation, Validierungsschichten und Berechtigungskonzepte“.

Einen öffentlich bekannten Fall, in dem ein Betriebs-Agent über eine Logzeile manipuliert wurde, gibt es bisher nicht. Wie die Zahlen zu den Filtern zeigen, lässt sich so eine Anweisung aber auch nicht zuverlässig erkennen. Man kann nur begrenzen, was sie anrichtet, und dafür sind wieder die Rechte zuständig. Es hilft zum Beispiel, Agenten, die fremde Logs auswerten, keine Rechte zum Neustarten von Diensten zu geben.

Freigaben durch Menschen

Naheliegend ist, dass ein Mensch jede kritische Aktion freigibt. Ein Button „Approve“ unter „Ich starte jetzt den Dienst neu“ bringt allerdings wenig. Wer freigibt, muss sehen, welcher Befehl auf welchem System laufen soll. Dazu gehört auch, was im schlimmsten Fall passiert und wie man es zurücknimmt.

Aber auch mit guten Angaben lässt die Aufmerksamkeit nach. Hat ein System hundertmal richtig gelegen, klickt man beim nächsten Mal durch, ohne zu lesen. Lisanne Bainbridge hat das 1983 in „Ironies of Automation“ beschrieben, Uwe Friedrichsen hat es 2025 auf KI-Agenten übertragen. Bainbridges Punkt war, dass Menschen, die nur noch überwachen, die Übung für den seltenen Ernstfall verlieren.

Zum Teil lässt sich das messen. Wie lange schauen Leute vor einer Freigabe hin, und wie oft lehnen sie ab? Gehen beide Werte gegen null, wird wahrscheinlich nur noch durchgeklickt. Freigaben sollte es deshalb nur dort geben, wo sie etwas entscheiden. Das Team sollte außerdem das, was der Agent nachts erledigt, weiterhin selbst können.

Auch der Agent muss betrieben werden

Mit dem Agenten kommt ein weiteres System in den Betrieb, das sich verändert, ohne dass im Team jemand etwas tut. Der Anbieter passt das Modell an, manchmal ohne neuen Versionsnamen. Runbooks und Prompts veralten, und Rechte, die für einen Sonderfall dazukamen, nimmt selten jemand wieder weg. Robert Glaser beschreibt die Arbeitsumgebung eines Teams mit Agenten deshalb als etwas mit eigenem Backlog, das neben der Feature-Arbeit gepflegt werden muss. Roman Stranghöner vergleicht es mit der Instandhaltung in Fabriken, wo Total Productive Maintenance klärt, wer für die Verfügbarkeit einer Anlage zuständig ist. In Teams mit Agenten ist das laut Stranghöner heute meist nicht klar geregelt.

Der Agent braucht also einen Owner, eine Person oder ein Team. Dazu gehören feste Testszenarien, mit denen man regelmäßig prüft, ob er noch wie erwartet reagiert, und ein Termin, an dem jemand seine Rechte durchsieht.

Wer verantwortet, was der Agent tut

Das NCSC ist da eindeutig: „A system may take an action, but humans remain accountable for: the decision to deploy it, the access it was granted, the safeguards around it, the consequences of its operation.“ Die Behörde empfiehlt, vor dem ersten Einsatz festzulegen, wem der Agent gehört, wer seine Zugriffe genehmigt, wer ihn überwacht und wer ihn stoppen kann. Als Prüfstein taugt ein weiterer Satz daraus: „If you cannot understand, monitor or contain an agent’s actions, it is not ready for deployment.“

Unter ISO 27001 ist ein Agent mit Admin-Rechten ein weiterer privilegierter Zugang, für den dieselben Regeln zu Rechtevergabe und Protokollierung gelten wie für jeden Admin. Unternehmen, die unter die EU-Richtlinie NIS2 fallen, müssen Konzepte zur Zugriffskontrolle nachweisen, und der Agent gehört dort hinein.

Quellen

Fazit

Sieben Fragen vor dem ersten Login

Bevor sich ein Agent zum ersten Mal auf einem Produktionsserver anmeldet, sollte das Team ein paar Fragen beantworten können:

  • Welche Aufgaben soll er übernehmen, und welche davon lassen sich nicht zurücknehmen?
  • Steht im Log sein eigener Name und der Name dessen, der ihn beauftragt hat?
  • Wie schnell ist er ausgesperrt, wenn etwas schiefgeht?
  • Setzt das Zielsystem die Grenze durch oder nur ein Prompt oder eine Befehlsliste?
  • Wo liegen die Backups, und wann wurde zuletzt ein Restore getestet?
  • Liest er Text von außen, und mit welchen Rechten?
  • Wer ist für ihn zuständig?

Solange mehrere davon offen sind, würde ich den Agenten nur lesend arbeiten lassen.

TAGS