KI-Agenten an der eigenen Infrastruktur: So setzen Sie Grenzen

Kurz gesagt: Ein KI-Agent, der Server, Firewall oder Git-Plattform einrichtet, macht dieselben Fehler wie ein Mensch, nur schneller. Anweisungen im Prompt schützen davor nicht, harte Grenzen schon. Acht Regeln reichen: eigenes Konto mit wenig Rechten, ein eigenes Netz für Wegwerf-Umgebungen, Merge nur durch Menschen, eine Sicherheitsprüfung, die Aktionen stoppen darf, keine Secrets in Git oder Chat, Backups, die der Agent nicht löschen kann, Monitoring ab der ersten Maschine und eine klare Aufteilung, was der Mensch erledigt.

Warum Regeln im Prompt nicht reichen

„Bitte nichts auf main pushen“ ist eine Bitte, keine Grenze. Ein Agent kann sie vergessen, missverstehen oder ein Subagent bekommt sie gar nicht erst mit. Verlässlich ist nur, was der Server durchsetzt: Rechte, die das Konto nicht hat, kann der Agent auch nicht versehentlich nutzen.

Die folgenden Regeln haben wir beim Aufbau eines internen Labors mit Claude Code erprobt: Proxmox, eine OPNsense-Firewall, Forgejo als Git-Plattform mit CI, Proxmox Backup Server und Checkmk. Sie lassen sich auf jede vergleichbare Umgebung übertragen. Warum Agenten überhaupt eine abgegrenzte Umgebung brauchen, beschreibt unser Beitrag über echte Sandboxes für KI-Agenten.

Regel 1: Geben Sie dem Agenten eine eigene Identität

Der Agent arbeitet nie mit Ihrem Konto und nie mit einem Admin-Token, sondern mit einem eigenen Konto ohne Administratorrechte.

Legen Sie ein eigenes Benutzerkonto für den Agenten an. Er ist weder Owner der Organisation noch Admin.
Geben Sie ihm nur Schreibrechte auf die Repositories, an denen er arbeitet.
Erzeugen Sie einen Token pro Rechner, auf dem der Agent läuft, mit so wenigen Berechtigungen (Scopes) wie möglich. Geht ein Rechner verloren, sperren Sie genau einen Token.
Löschen Sie Tokens, die nicht mehr gebraucht werden oder zu weit gefasst sind, sofort.
Behandeln Sie initiale Zugangsdaten als verbrannt. Das erste Admin-Passwort und der erste Admin-Token einer neuen Installation tauchen fast immer irgendwo auf: in der Shell-History, im Chatverlauf mit dem Agenten, in Logs oder im Installationsskript. Nutzen Sie sie nur, um das Agentenkonto einzurichten, und tauschen bzw. löschen Sie sie danach.

So bleibt in jedem Log nachvollziehbar, was der Agent getan hat und was ein Mensch.

Die Regel gilt für dauerhafte, gemeinsam genutzte Systeme, und ganz besonders für das Git-Repository. Es ist vom ersten Commit an produktiv: Dort liegt die Historie, auf die sich alle verlassen, von dort baut die CI, und was einmal im Hauptzweig steht, lässt sich nur mühsam wieder herausholen. Eine Testphase, in der man es „erst mal locker“ angehen kann, gibt es beim Repository nicht. In einem Wegwerf-Container oder einer Wegwerf-VM ohne Zugriff auf produktive Daten darf der Agent ruhig root sein. Dort begrenzt die Umgebung den Schaden, nicht das Konto, vorausgesetzt, die Umgebung ist auch im Netz abgegrenzt (Regel 2).

Aus der Praxis: Beim Einrichten der Git-Plattform entstand zuerst ein Token für das Admin-Konto, ein typisches Initial-Credential. Er funktionierte nicht einmal, weil ein erzwungener Passwortwechsel beim Admin auch die API sperrt. Für die Arbeit des Agenten war er ohnehin nie gedacht: Der Agent bekam sein eigenes Konto, der Admin-Token wurde gelöscht.

Regel 2: Geben Sie Wegwerf-Umgebungen ein eigenes Netz

Root in einer Wegwerf-VM ist nur dann harmlos, wenn die VM nirgendwo hinkommt. Ein Container, der in Ihrem Büronetz hängt, sieht Ihre Server, Drucker und Freigaben, egal wie oft Sie ihn wegwerfen. Deshalb gehören Agenten-Umgebungen in ein eigenes Netzsegment hinter einer Firewall.

Ein VLAN allein reicht nicht. Es trennt nur auf Layer 2. Kontrolliert wird erst, wenn ein Router mit Firewall-Regeln zwischen den Netzen sitzt. Wir haben dafür in Proxmox eine interne Bridge ohne physischen Port angelegt und eine OPNsense-VM als Router und Firewall davorgesetzt. Elegant ist das nicht: Die WAN-Seite der virtuellen Firewall hängt im eigenen Netz und teilt sich mit ihm denselben physischen Port des Hosts. Für den Start ist das vertretbar. Sauberer sind getrennte physische Ports, und dafür genügt schon eine Netzwerkkarte mit mehreren Anschlüssen. Eine Hardware-Firewall lohnt sich aus anderen Gründen: Sie bleibt unabhängig vom Hypervisor, und sie trennt auch dann noch, wenn sich die Dienste über mehrere Hosts verteilen.
Der Weg ins eigene Netz ist gesperrt. Aus dem Segment heraus geht es höchstens ins Internet.
Auch „nur ins Internet“ ist nicht harmlos. Wer Pakete holen darf, kann auch Daten hinausschicken, fremde Dienste als Sprungbrett nutzen oder einen Paket-Proxy als Umweg missbrauchen. Genau so sind Agenten beim Hugging-Face-Vorfall aus einer Testumgebung ohne freien Internetzugang herausgekommen. Je restriktiver, desto besser: ein Paket-Proxy, der nur fest eingetragene Repositories bedient, dahinter ein Egress-Proxy mit erlaubten Zielen. Für ein Labor kann ein offener Weg ins Internet ein bewusst akzeptiertes Risiko sein, aber dann bitte dokumentiert und nicht einfach vergessen. Für Umgebungen mit echten Daten ist er das nicht.
In das Segment hinein nur gezielte Freigaben: Einzelne Dienste werden per DNAT ins eigene Netz veröffentlicht, nicht mehr. Bei uns sind das die Git-Plattform und der Password Pusher, dazu der Zugriff des Monitorings und Admin-SSH über einen festen Sprung-Host. Aus dem Internet ist nichts erreichbar.
Standardregeln ersetzen, nicht ergänzen. Viele Firewalls bringen „Allow all“-Regeln für das interne Netz und eine Anti-Lockout-Regel mit, die vor Ihren eigenen Regeln greifen. Deaktivieren Sie sie und schreiben Sie ausdrücklich, was erlaubt ist.
IPv6 nicht vergessen. „Isoliert“ gilt pro Protokollfamilie. Ein Segment, das unter IPv4 dicht ist, kann über IPv6 direkt im Internet stehen.
Testen Sie von der falschen Seite. Eine Regel zählt erst, wenn ein Verbindungsversuch aus dem Segment ins eigene Netz tatsächlich scheitert.

Aus der Praxis: Unsere Regel „Segment darf nicht ins eigene Netz“ griff zunächst nicht, die Test-VM erreichte den Hausrouter. Die eingebaute OPNsense-Regel „Default allow LAN to any“ wurde vor unseren eigenen Regeln ausgewertet, und die Anti-Lockout-Regel hätte jeder VM im Segment Zugriff auf die Oberfläche der Firewall gegeben. Beide sind jetzt aus. Kurz darauf hatte der Proxmox-Host auf der „isolierten“ Bridge plötzlich eine öffentliche IPv6-Adresse: Die Werkskonfiguration der OPNsense holte sich ein Präfix vom Provider und verteilte es weiter. Ohne Test von der falschen Seite wäre beides unbemerkt geblieben.

Regel 3: Mergen dürfen nur Menschen

Der Agent arbeitet in Branches und öffnet Pull Requests. Ein Mensch prüft und mergt. Setzen Sie das technisch durch:

Branchschutz auf dem Hauptzweig: kein direkter Push, Merge nur über Pull Request mit mindestens einer Freigabe.
Das Agentenkonto darf eigene Pull Requests weder freigeben noch mergen.
Neue Repositories legen nur Menschen an. Achten Sie darauf, dass der Agent die Regel nicht umgehen kann, etwa durch ein Repository unter seinem eigenen Konto.

Arbeiten mehrere Agenten oder Subagenten parallel, brauchen sie dieselbe Git-Disziplin wie ein Team, nur strikter. Dabei hilft es, zwei Begriffe sauber zu trennen:

Ein Branch ist ein Entwicklungsstrang in der Historie, also eine Folge von Commits mit einem Namen. Er sagt, worauf gearbeitet wird.
Ein Worktree ist ein zusätzliches Arbeitsverzeichnis, in dem ein Branch ausgecheckt ist. Er sagt, wo gearbeitet wird: mit eigenen Dateien, eigenem Index und eigenem HEAD, aber über dasselbe Repository und dieselbe Historie.

Mit Branches allein teilen sich parallele Agenten ein einziges Arbeitsverzeichnis. Wechselt einer den Branch, ändern sich die Dateien unter allen anderen, und halbfertige Änderungen landen im falschen Commit. Erst ein eigener Worktree pro Aufgabe trennt die Arbeit wirklich. git worktree gibt es seit Git 2.5 aus dem Jahr 2015, lange vor KI-Agenten. Agenten nutzen es aber besonders gern, weil es Isolation ohne zweiten Klon liefert. Claude Code startet eine Session mit claude --worktree <name> direkt in einem eigenen Worktree auf eigenem Branch.

Das gilt nicht nur für Agenten untereinander. Auch der Mensch arbeitet in seinem eigenen Worktree, auf derselben Maschine und parallel zum Agenten. Niemand muss warten, bis der andere fertig ist, und niemand schreibt dem anderen in halbfertige Dateien.

Daraus folgen drei Regeln:

Eine Aufgabe, ein Branch, ein Worktree. Git verhindert dabei von sich aus, dass derselbe Branch in zwei Worktrees gleichzeitig ausgecheckt wird. Diese Sperre sollte niemand mit --force umgehen.
Vor jedem Commit den aktuellen Branch prüfen. Ein Subagent weiß nicht automatisch, in welchem Worktree und auf welchem Branch er steht.
Worktrees nach dem Merge aufräumen (git worktree remove), zusammen mit dem gemergten Branch. Sonst sammeln sich verwaiste Arbeitsverzeichnisse.
Konflikte per Rebase lösen und versehentlich zu früh gemergte Änderungen per Cherry-Pick nachziehen, statt die Historie umzuschreiben.

Aus der Praxis: Bei uns committete ein Subagent auf den lokalen Hauptzweig, ein Pull Request wurde zu früh gemergt, und parallele Pull Requests kollidierten bei der Versionsnummer. Branch-Check, Worktrees, Cherry-Pick und Rebase haben jeden dieser Fälle sauber aufgefangen. Den eigenen Pull Request mergen konnte der Agent nie, der Server antwortete mit HTTP 405.

Wie mehrere Sessions miteinander kommunizieren, zeigt unser Beitrag zu Cross-Session Messaging in Claude Code.

Regel 4: Lassen Sie riskante Aktionen prüfen, und nehmen Sie das Nein ernst

Ein Agent mit Shell-Zugriff braucht eine Instanz, die Aktionen vor der Ausführung bewertet. In Claude Code gibt es dafür mehrere Ebenen:

Berechtigungsregeln: Mit permissions.deny in den Einstellungen verbieten Sie bestimmte Befehle oder Werkzeuge grundsätzlich.
Sandbox: Bash-Befehle laufen auf Wunsch mit Dateisystem- und Netzwerk-Isolation (/sandbox).
Automatischer Modus: Ein separates Klassifikator-Modell bewertet die Aktionen des Agenten und blockiert, was es für unsicher hält. Ihre eigenen Allow- und Deny-Regeln gelten weiter.

Entscheidend ist der Umgang mit einer Absage: Suchen Sie nicht nach einem Weg drumherum, sondern nach einer besseren Lösung. Fast immer gibt es eine.

Aus der Praxis: Dreimal hat die Prüfung bei uns gestoppt. Ein temporärer HTTP-Server, um Skripte auf die neue OPNsense zu bringen, hätte einen Dienst im Netz geöffnet. Die Alternative war eine Dateiübertragung über die serielle Konsole der VM, danach lief alles über die Firewall-API. Ein automatischer Push der Firewall-Konfiguration ins Git hätte Zugangsdaten offengelegt (siehe Regel 5). Und ein Repository unter dem Agentenkonto hätte Regel 3 ausgehebelt. Jedes Mal war die Lösung danach sauberer als der ursprüngliche Plan.

Regel 5: Keine Secrets in Git, keine Secrets im Chat

Infrastructure as Code ist richtig, aber nicht um den Preis von Zugangsdaten im Repository. Prüfen Sie vor jedem automatischen Konfigurations-Backup ins Git, was die Datei enthält. Bei Firewalls stecken darin oft Passwort-Hashes, API-Secrets, private Zertifikatsschlüssel und sogar der Deploy-Key für das Backup selbst.

Bewährt hat sich die Trennung:

Sicherung der Konfiguration über das verschlüsselte VM-Backup,
Nachvollziehbarkeit über ein Änderungsprotokoll,
Soll-Zustand in einem Skript, das man beliebig oft ausführen kann und das selbst keine Secrets enthält.

Passwörter und Tokens gehören auch nicht in den Chatverlauf mit dem Agenten. Übergeben Sie sie über Einmal-Links (zum Beispiel einen selbst betriebenen Password Pusher) oder über eine Datei, die nur der Benutzer des Agenten lesen darf (Rechte 600). Prüfen Sie vor dem Verschicken, ob der Inhalt plausibel ist, mindestens seine Länge.

Aus der Praxis: Ein Skript brach ab, bevor es ein Passwort ausgelesen hatte, und erzeugte trotzdem einen Einmal-Link, mit leerem Inhalt. Seitdem prüfen wir vor dem Versand die Länge. Das OPNsense-Plugin os-git-backup haben wir nach der Prüfung wieder entfernt.

Regel 6: Schützen Sie die Backups, auch vor dem Agenten

Backups mit dem Proxmox Backup Server kann der Agent ruhig mit einrichten. Er darf sie aber nicht löschen können, weder absichtlich noch durch eine falsch verstandene Aufräum-Anweisung. Was der Agent abräumen kann, ist im Ernstfall kein Backup.

Nur sichern, nicht löschen: Geben Sie dem Agenten die Rolle DatastoreBackup. Sie erlaubt, Backups anzulegen und eigene wiederherzustellen, aber nicht, bestehende zu löschen oder zu ändern. Rollen mit dem Recht Datastore.Prune bekommt der Agent nicht.
Aufbewahrung legt der Mensch fest: Alte Backups räumt ein Prune-Job direkt auf dem Backup-Server ab, nicht der Client. So empfiehlt es auch die Proxmox-Dokumentation. Die Regeln (keep-last, keep-daily …) setzt und ändert ein Mensch, und er prüft nach dem Einrichten, ob der Job wirklich läuft.
Ein Datenträger, der nicht dauerhaft gemountet ist: Ein zusätzlicher Wechseldatenträger als Air Gap wird nur zum Abgleich eingebunden und danach wieder getrennt. Der Proxmox Backup Server unterstützt dafür Wechsel-Datastores, die sich ein- und aushängen lassen. Was nicht eingebunden ist, kann weder ein Agent noch eine Ransomware löschen.
Den Schlüssel getrennt verwahren: Liegt der Schlüssel eines verschlüsselten Backups nur auf dem Host, der ausfallen kann, nützt das Backup nichts.
Restore testen: Ein Backup ohne Restore-Test ist eine Hoffnung. Spielen Sie regelmäßig eine Sicherung als isolierte VM zurück.

Aus der Praxis: Beim Einrichten meldete der Backup-Speicher „Datastore nicht gefunden“, obwohl er existierte. Ursache: Ein API-Token bekommt in Proxmox nur die Schnittmenge seiner eigenen Rechte und der Rechte seines Benutzers, die Berechtigung braucht es also für beide. Ein Prune-Job hatte einen ungültigen Kalenderausdruck, und weil die Fehlerausgabe unterdrückt war, fiel das zunächst nicht auf. Der Restore-Test der Git-Plattform als isolierte VM lief danach fehlerfrei.

Regel 7: Monitoring ab der ersten Maschine

Ein Agent übersieht Nebenwirkungen genauso wie ein Mensch. Er muss nicht perfekt sein, die Überwachung muss es Ihnen sofort sagen. Deshalb gehört Monitoring an die erste virtuelle Maschine, nicht erst an die letzte.

Typisch sind zwei Arten von Fallen:

Fallen der Agenten selbst. Agenten starten Teil-Agenten und Hintergrundprozesse, die weiterlaufen, auch wenn der Bericht längst vorliegt. Und sie melden „fertig“, wenn ihr Skript durchgelaufen ist, nicht unbedingt, wenn das Ergebnis stimmt. Machen Sie sichtbar, was läuft, und prüfen Sie das Ergebnis, nicht die Erfolgsmeldung.
Ganz normale Infrastruktur-Fallen. Viele Stolpersteine haben mit dem Agenten nichts zu tun, sie erwischen Menschen genauso. Der Agent tappt nur schneller und öfter hinein, weil er mehr in kürzerer Zeit einrichtet. Zwei Beispiele aus unserem Aufbau finden Sie unten. Ein Hinweis, weil die Namen ähnlich klingen: cloud-init ist das Einrichtungswerkzeug für Linux-VMs und Cloud-Images und hat mit Claude nichts zu tun.
Prüfen Sie Ihre Checks. Ein Check ist erst fertig, wenn Sie seinen Zustand einmal gesehen haben. In Checkmk etwa sind die Schwellen 30;14 Obergrenzen, für eine Zertifikatslaufzeit („weniger als 30 Tage“) braucht es 30:;14:.

Aus der Praxis: Nach einem Neustart fand unser CI-Runner die Git-Plattform nicht mehr. cloud-init hatte /etc/hosts neu geschrieben, Proxmox aktiviert das für seine VMs standardmäßig, und ein manueller Eintrag war weg. Aufgefallen ist das erst, als ein Pull Request keinen CI-Lauf bekam, nach 25 Neustarts des Dienstes. Ein anderes Setup-Skript meldete „fertig“, aber Docker fehlte: cloud-init hielt beim ersten Start noch die apt-Sperre, und set -e hatte bei einer &&-Kette nicht abgebrochen. Und Teil-Agenten eines Prüf-Agenten liefen noch, als ihr Ergebnis längst da war, bis die Frage kam: „Was läuft da seit 7 Stunden 45 Minuten?“

Regel 8: Planen Sie die Reibung ein

Grenzen bremsen spürbar. Das ist kein Mangel, sondern ihre Wirkung. Legen Sie vorher fest, wer was erledigt. Entwickeln dürfen beide, jeweils im eigenen Worktree. Die Unterschiede liegen bei Freigaben, Rechten und allem, was nach außen wirkt:

Aufgabe	Agent	Mensch
Code und Konfiguration schreiben, testen	✓	✓
Pull Request öffnen	✓	✓
Pull Request des Agenten prüfen		✓
Pull Request freigeben und mergen		✓
Neue Repositories anlegen		✓
Tokens erzeugen und Secrets übergeben		✓
DNS-Einträge, Firewall-Freigaben nach außen		✓
Monitoring-Alarme auswerten	✓	entscheidet

Und seien Sie ehrlich zu sich: Mehrfaktor-Anmeldung und ein Security-Review gehören zum Abschluss dazu. Bei uns standen beide zuletzt noch aus, die Abnahme listete zwölf Restrisiken.

Checkliste: KI-Agenten an der eigenen Infrastruktur

Eigenes Konto für den Agenten, ohne Owner- und Admin-Rechte.
Ein eng begrenzter Token pro Rechner, alte Tokens sofort löschen, initiale Zugangsdaten nach der Einrichtung tauschen.
Wegwerf-VMs und Container in ein eigenes Segment hinter einer Firewall: kein Weg ins eigene Netz, Internet so restriktiv wie möglich, nur einzelne Dienste hinein, IPv6 mitprüfen, von der falschen Seite testen.
Geschützter Hauptzweig, mergen nur durch Menschen.
Neue Repositories nur durch Menschen, ohne Umweg über das Agentenkonto.
Eine Aufgabe, ein Branch, ein Worktree, Branch-Check vor jedem Commit, Worktrees nach dem Merge entfernen.
Sicherheitsprüfung aktiv, Deny-Regeln für Kritisches, Absagen nicht umgehen.
Keine Secrets in Git, Übergabe per Einmal-Link, Inhalt vorher prüfen.
Backups: Agent darf sichern, nicht löschen; Aufbewahrung durch Menschen; ein nicht dauerhaft eingebundener Datenträger; Restore testen.
Monitoring ab der ersten Maschine, Checks einmal im Zustand sehen.
Hintergrundprozesse von Agenten sichtbar machen und beenden.
Aufgabenteilung Agent/Mensch vorab festlegen.

Häufige Fragen

Darf ein KI-Agent Administratorrechte bekommen? In Wegwerf-Umgebungen ja: In einem Container oder einer VM, die nach der Aufgabe gelöscht wird und keinen Zugriff auf produktive Daten, Secrets oder Netze hat, darf der Agent root sein, sofern sie in einem eigenen, abgeschotteten Netzsegment läuft. Genau dafür ist eine Sandbox da. Auf dauerhafter, gemeinsam genutzter Infrastruktur wie Git-Plattform, Firewall oder Servern gilt dagegen: eigenes Konto mit genau den Rechten, die die Aufgabe braucht. Was darüber hinausgeht, erledigt ein Mensch.

Wie verhindere ich, dass ein KI-Agent ungeprüften Code in den Hauptzweig bringt? Mit Branchschutz auf dem Server, nicht mit einer Anweisung im Prompt. Der Agent darf Pull Requests öffnen, aber weder freigeben noch mergen.

Wie gebe ich einem KI-Agenten Passwörter, ohne dass sie im Chatverlauf landen? Über Einmal-Links oder eine Datei mit Rechten 600, die nur der Agent liest. Prüfen Sie vorher, ob überhaupt etwas Sinnvolles übergeben wird.

Fazit

Ein KI-Agent kann Infrastruktur erstaunlich zügig aufbauen. Sicher wird das nicht durch Vertrauen, sondern durch Grenzen, die der Server durchsetzt, und durch ein Monitoring, das Fehler meldet, bevor sie sich verstecken.

Die Regeln in diesem Beitrag stammen aus einem Labor, und genau dafür ist ein Labor da: Dort testet man Grenzen bewusst aus. Was sich dort bewährt, übernehmen wir in den produktiven Betrieb, was nicht, dokumentieren wir.

Wann sich Agenten statt einfacher Skills lohnen, lesen Sie in KI-Agenten vs. Skills.

Sie möchten KI-Agenten in Ihrem Betrieb einsetzen, ohne die Kontrolle abzugeben? Mehr zu unserer Serverbetreuung – oder sprechen Sie uns direkt an.

Quellen: Claude Code – Sicherheit und Berechtigungsmodi · Git – git-worktree · Claude Code – Parallele Sessions mit Worktrees · Forgejo – Geschützte Branches · Proxmox Backup Server – Benutzer und Rechte · Proxmox Backup Server – Datastores und Wechsel-Datastores · cloud-init – Modul Update Etc Hosts (manage_etc_hosts) · Checkmk – Lokale Checks: Schwellwerte · GNU Bash – set -e