# KI-Agenten gehören nicht auf den Entwickler-Laptop > Coding-Agenten brauchen weitreichende Rechte. Darum gehören sie in isolierte, kurzlebige Umgebungen einer KI-Softwarefabrik statt auf den Entwickler-Laptop. - URL: https://seiler.it/articles/ki-agenten-entwickler-laptop/ - Author: Dr. Sven Seiler (https://seiler.it/) - Type: Article - Language: de - Published: 2026-10-29 - Updated: 2026-10-29 **Coding-Agenten und KI-Tools benötigen umfangreiche Systemrechte, um effizient zu arbeiten. Darum sollten sie in einer Umgebung laufen, in der Fehlentscheidungen möglichst wenig Schaden anrichten können.** Dieser Beitrag erschien zuerst am 15. Oktober 2026 bei [COMPUTERWOCHE](https://www.computerwoche.de/article/4232566/ki-agenten-gehoren-nicht-auf-den-entwickler-laptop.html) im Experten-Netzwerk von Foundry. Ein Entwickler diskutiert eine neue Anforderung mit einem KI-Agenten: In einer Unternehmensanwendung soll künftig sichtbar werden, wie viele [Token](https://www.computerwoche.de/article/4182846/ki-token-erklart.html) einzelne Aufgaben verbrauchen und welche Kosten dadurch entstehen. Der Agent stellt mithilfe des Brainstorming-Skills von Superpowers so lange Fragen, bis die Anforderung geklärt ist. Daraus entsteht ein Ticket. Nach menschlicher Freigabe startet in der Cloud eine isolierte Instanz. Ein Coding-Agent implementiert das Feature, ein zweiter Agent (von einem anderen Anbieter) prüft den Code und am Ende steht ein Pull Request zur Freigabe bereit. Rund 30 Minuten später ist das neue Dashboard fertig und zeigt die zuvor abgestimmten [Metriken](https://www.computerwoche.de/article/4162708/diese-kennzahl-fehlt-auf-jedem-ki-dashboard.html). Auf dem Laptop des Benutzers wurde währenddessen keine einzige Zeile Code verändert. Das ist kein Nebeneffekt, sondern Teil des Sicherheitskonzepts. Damit ein Coding-Agent produktiv arbeiten kann, benötigt er weitreichende Rechte. Er gehört deshalb nicht auf denselben Rechner, auf dem auch E-Mails, Kundendaten und Zugangsschlüssel liegen. Besser aufgehoben ist er in einer isolierten, kurzlebigen Umgebung – einer „KI-Softwarefabrik“. ## Das Freigabe-Problem von Agentic Engineering Wer lokal mit einem Agenten arbeitet, kennt das Problem: Der Agent möchte Dateien lesen, schreiben oder löschen, Pakete installieren oder Tests starten und fordert dafür immer wieder eine Freigabe an. Das kann dazu führen, dass Nutzer die ständigen Abfragen irgendwann deaktivieren und dem Agenten umfangreiche Rechte einräumen. Die Dokumentation von Claude Code[^1] weist beispielsweise darauf hin, dass selbst ein isolierter Docker-Container ein Projekt mit schadhaftem Programmcode nicht daran hindert, auf Daten zuzugreifen, die innerhalb des Containers erreichbar sind. Anthropic rät daher ausdrücklich davon ab, SSH-Schlüssel oder andere sensible Host-Credentials in eine solche Umgebung einzubinden. Die Risiken weitreichender Berechtigungen wurden bereits im Juli 2025 prominent diskutiert. Der Gründer von SaaStr, [Jason Lemkin](https://www.linkedin.com/in/jasonmlemkin), dokumentierte, wie sein Entwicklungs-Agent trotz eines Code-Freezes die Produktionsdatenbank löschte. Der Agent bezeichnete diesen Vorfall später als „a catastrophic error of judgement[^2]“. Er hatte zwar die Anweisung erhalten, keine produktiven Daten zu löschen, verfügte technisch jedoch über die notwendigen Rechte, genau das zu tun. Zwei typische Risikoszenarien verdeutlichen das Problem: Ein Agent räumt ein Build-Verzeichnis auf und löscht dabei versehentlich einen lokalen Branch, der nie gepusht wurde. Ein halber Arbeitstag ist verloren. Ein Agent liest eine präparierte README in einer eingebundenen fremden Bibliothek, folgt einer darin [versteckten Anweisung](https://www.computerwoche.de/article/4190978/so-spuren-sie-kompromittierte-ki-agenten-auf.html) und schickt Zugangsdaten an einen fremden Server. Entwicklungsexperte [Simon Willison](https://www.linkedin.com/in/simonwillison) bezeichnet solche Konstellationen als „Lethal Trifecta[^3]“. Die Gefahr ergibt sich dabei aus der Kombination von drei Fähigkeiten: Zugriff auf nicht vertrauenswürdige Inhalte, Zugang zu privaten Daten und die Möglichkeit, Informationen nach außen zu übertragen. Ein Entwickler-Laptop kann alle drei Bedingungen erfüllen. OWASP führt dieses Risiko in den Top 10 für LLM-Anwendungen unter dem Begriff „Excessive Agency[^4]“: Gemeint sind Systeme, denen mehr Funktionen, Berechtigungen oder Autonomie eingeräumt werden, als für ihre Aufgabe erforderlich sind. Wie schnell sich Sicherheitsvorfälle dieser Art heute entwickeln können, war auch Thema einer Expertenrunde der Computerwoche zu „[IT- und Cloud Security 2026](https://www.computerwoche.de/article/4178278/it-security-und-ki-kontrollverlust-in-sekundenschnelle.html)“. Die Alternative, jede Aktion einzeln bestätigen zu lassen, löst das Problem nur bedingt. Agenten-basierte Softwareentwicklung verliert einen großen Teil ihrer Effizienzvorteile, wenn ständig manuelle Freigaben erforderlich sind. ## Wegwerfbare Umgebungen statt Vertrauen Viele Einzelentwickler nutzen deshalb einen eigenen Entwicklungsserver. So lief es auch in meinem konkreten Fall: Ich habe mit [Vibe Coding](https://www.computerwoche.de/article/3854442/vibe-coding-im-selbstversuch.html) im August 2025 begonnen – zunächst lokal und später aus Sicherheitsgründen auf einem eigenen Server, bei dem ein Ausfall oder Datenverlust verschmerzbar wäre. Dort liegen mittlerweile über 70 Projekte – die Anwendungen laufen in Docker-Containern. Für einen einzelnen Entwickler funktioniert dieses Modell gut. Doch auch die Grenzen dieses Ansatzes zeigen sich schnell: Beim Ausrollen von Infrastruktur über AWS CDK wurde versehentlich der Stand der Staging-Umgebung direkt auf die Produktion geschrieben. Der Fehler fiel sofort auf, ließ sich stoppen und zurückrollen. Das grundlegende Risiko bleibt jedoch bestehen: Hat ein Agent Zugriff auf Produktivsysteme, kann er dort Schaden anrichten, unabhängig davon, wie sauber seine Entwicklungsumgebung getrennt ist. Eine weitere Hürde ist die Zusammenarbeit im Team: Wenn mehrere Menschen an Projekten arbeiten, nutzen sie unterschiedliche Umgebungen und haben jeweils andere Zugänge zu Agenten, etwa über [API](https://www.computerwoche.de/article/4004872/die-besten-apis-um-ki-zu-integrieren.html)-Token, Subskriptionen oder lokale Modelle. Ohne eine gemeinsame Plattform fehlt zudem die zentrale Kontrolle darüber, welcher Agent wann welche Aktionen ausgeführt hat. Das ist die Stelle, an der die „AI Software Factory“ ins Spiel kommt – und den Ansatz umdreht. Statt den Handlungsspielraum des Agenten immer weiter einzuschränken, wird seine Laufzeitumgebung so isoliert und kurzlebig gestaltet, dass die Folgen eines Fehlschlags möglichst begrenzt bleiben. Dabei muss diese Umgebung so entbehrlich und abgeschottet sein, dass sie nach einem fehlgeschlagenen Lauf einfach verworfen werden kann. Technisch lässt sich das beispielsweise mit Micro-VMs, also minimal ausgestatteten [virtuellen Maschinen](https://www.computerwoche.de/article/2814705/was-sind-virtual-machines.html), in der Cloud umsetzen. Wie ressourcenschonend dieser Ansatz sein kann, zeigt Firecracker – ursprünglich von AWS für Dienste wie Lambda und Fargate entwickelt: Eine Micro-VM startet in weniger als 125 Millisekunden und benötigt weniger als 5 MiB Overhead[^5]. In dieser Maschine läuft nur der Agent mit seinem zugeschnittenen [Harness](https://www.computerwoche.de/article/4216923/ai-harness-die-neue-angriffsflache-die-sie-nicht-im-blick-haben.html): Er holt den Code, arbeitet mit den für seine Aufgabe erforderlichen Rechten und liefert das Ergebnis als Pull Request ab. Wenn er die Maschine „gegen die Wand fährt“ oder Dateien löscht, wird sie anschließend verworfen. Eine solche Instanz besteht in diesem Modell höchstens acht Stunden. Wartet der Agent auf eine Antwort, kann sie vorübergehend pausiert werden, um unnötige Kosten zu vermeiden. Die meisten Läufe dauern 20 bis 30 Minuten. Bei rechenintensiven Coding-Agenten können die Ausgaben für die Modellnutzung die reinen Infrastrukturkosten deutlich übersteigen. Die zusätzliche Isolation fällt wirtschaftlich damit häufig weniger ins Gewicht als die Kosten für Modelle und Token. Auch die Identität des Agenten wird bei diesem Ansatz von der des Entwicklers getrennt. Dafür erhält er beispielsweise über eine GitHub-App eigene, eng begrenzte Rechte. Persönliche Token der Entwickler werden nicht verwendet. Ein Audit-Log macht nachvollziehbar, welcher Agent welche Aktionen ausgeführt hat. Der Start des Agenten folgt dabei einem kontrollierten Prozess. Ein Ticket im System löst über einen Hook einen Lauf aus: Ein Label, ein Kommentar oder ein Pull Request triggert den Agenten in der „AI Software Factory“. Die Plattform prüft die Rahmenbedingungen und startet je nach Aufgabe einen oder mehrere Agenten. So entsteht eine Kette: Der Implementierungs-Agent schreibt den Code und öffnet einen Pull Request. Ein Review-Agent mit einem anderen Modell, idealerweise von einem anderen [LLM](https://www.computerwoche.de/article/4155050/25-fragen-die-zum-richtigen-llm-fuhren.html)-Anbieter, prüft den Code. Seine Befunde können automatisch eine weitere Runde des Implementierungs-Agenten auslösen. Erst wenn die automatisierten Prüfungen abgeschlossen sind, übernimmt ein Mensch das abschließende Review. Die Branch Protection verlangt dafür zwei Freigaben, eine vom Review-Agenten und eine vom Menschen. Auch der Staging-Vorfall wäre in einer solchen Architektur über Pull Requests und Pipelines gelaufen und nicht direkt aus einer Sitzung heraus. Alle Agenten arbeiten zudem mit einem gemeinsamen Harness, also einem standardisierten Satz aus Werkzeugen, Skills und Prompts. Lokal nutzt jeder Entwickler potenziell andere Erweiterungen und Prompts, was zu inkonsistentem Code führen kann. In einer „KI-Softwarefabrik“ lassen sich diese Vorgaben zentral pro Projekt definieren. Wo regulatorische oder vertragliche Anforderungen eine Verarbeitung in Europa verlangen, kann auch die Ausführung auf entsprechend konfigurierte europäische Regionen begrenzt werden. ## Wo eine KI-Softwarefabrik Sinn macht Für einen Prototypen ist der „AI Software Factory“-Ansatz oft zu aufwendig. Ein eigener kleiner Server oder eine ausreichend isolierte Container-Umgebung kann dafür genügen. Bei reinen Wegwerf-Prototypen ohne Produktivbezug kann je nach Risiko auf eine menschliche Prüfung verzichtet werden. Für professionelle Softwareentwicklung mit produktivem Einsatz muss der Mensch dagegen in den Freigabeprozess [eingebunden bleiben](https://www.computerwoche.de/article/4225367/wenn-human-in-the-loop-nur-eine-illusion-ist.html). Agenten können Anweisungen ausführen und Ergebnisse prüfen, die Verantwortung für produktive Software verbleibt jedoch beim Menschen. Der Einstieg in ein kontrolliertes Modell ist einfach: Zuerst wird geklärt, wo Agenten laufen und mit welchen Zugangsdaten sie arbeiten dürfen. Dann erhält der Agent eine eigene Identität mit eingeschränkten Rechten. Schließlich werden Repositories so angebunden, dass Agenten über Tickets gestartet werden und in kurzlebigen, isolierten Umgebungen arbeiten. Coding-Agenten brauchen Handlungsspielraum. Sicher wird dieser erst, wenn Rechte, Identitäten und Ausführungsumgebung konsequent kontrolliert werden. ## Quellen [^1]: Anthropic: „Development containers“, Claude Code Docs, abgerufen 29. Oktober 2026. [code.claude.com](https://code.claude.com/docs/en/devcontainer) [^2]: Sharwood, Simon: „Vibe coding service Replit deleted production database“, The Register, 21. Juli 2025. [theregister.com](https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/) [^3]: Willison, Simon: „The lethal trifecta for AI agents: private data, untrusted content, and external communication“, Blogbeitrag, 16. Juni 2025. [simonwillison.net](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/) [^4]: OWASP: „LLM06:2025 Excessive Agency“, OWASP Top 10 for LLM Applications 2025. [genai.owasp.org](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) [^5]: Firecracker: Projektseite der Open-Source-Virtualisierung für Micro-VMs (Startzeit, Overhead je VM, Einsatz in AWS Lambda). [firecracker-microvm.github.io](https://firecracker-microvm.github.io/)