KI-Coding-Sandboxes reichen nicht. Entscheidend ist der Schadenradius.

KI-Coding-Agenten sind inzwischen mächtig genug, dass “kann das Tool den Code schreiben?” nicht mehr die spannendste Frage ist.

Die bessere Frage lautet:

Was passiert, wenn es falsch liegt?

Auf X wurde in den letzten 24 Stunden genau darüber diskutiert: Claude Code, Cursor, agentische Coding-Workflows, Sandboxing, Terminal-Zugriff, API-Tokens, Berechtigungsabfragen, “Yolo Mode”, Multi-Agent-Orchestrierung und Berichte über einen Netzwerk-Sandbox-Bypass in Claude Code.

Die nützliche Lehre für Gründer, CTOs, Product Owner und Mittelstandsteams ist nicht, dass KI-Coding-Tools vermieden werden sollten.

Die nützliche Lehre ist konkreter:

Sandboxes sind notwendig. Sie reichen aber nicht.

Wenn ein KI-Coding-Agent Dateien lesen, Tools aufrufen, Befehle ausführen, Pakete installieren, Konfiguration verändern oder MCP-Server nutzen kann, muss das Team den Schadenradius dieses Agenten bewusst gestalten.

Warum das jetzt relevant ist

Frühes KI-Coding war oft beratend.

Man fragte nach einer Funktion. Man kopierte eine Fehlermeldung. Man übernahm einen Codeausschnitt. Das Modell konnte falsch liegen, aber der Mensch war noch die klare Grenze zwischen Vorschlag und Systemänderung.

Diese Grenze ist dünner geworden.

Moderne Coding-Agenten können Repositories analysieren, viele Dateien verändern, Shell-Befehle ausführen, Tests starten, Tools anbinden, Dokumentation lesen, Branches erzeugen, Pull Requests öffnen und teilweise in Deployment- oder Betriebsprozesse hineinreichen. In manchen Teams arbeiten mehrere Agenten parallel an getrennten Aufgaben.

Das ist ein echter Produktivitätssprung.

Es ist aber auch ein echter Sicherheits- und Betriebswechsel.

Ein Tool, das nur Text vervollständigt, hat ein Risikoprofil. Ein Tool, das innerhalb einer Entwicklungsumgebung Befehle ausführen kann, hat ein anderes. Ein Tool, das Credentials nutzen, Systeme abfragen, Abhängigkeiten installieren oder verbundene Dienste aufrufen kann, gehört noch einmal in eine andere Kategorie.

An diesem Punkt hilft der Agent nicht mehr nur beim Tippen.

Er nimmt am Software-Liefersystem teil.

Eine Sandbox ist eine Schicht, keine Strategie

Sandboxing ist wichtig.

Berechtigungsabfragen sind wichtig. Netzwerk-Allowlisten sind wichtig. Dateisystem-Grenzen sind wichtig. Tool-Freigaben sind wichtig. Isolierte Umgebungen sind wichtig.

Aber keine einzelne Kontrolle sollte das gesamte Sicherheitsmodell tragen.

Das gilt in normaler Softwarearchitektur, und es gilt genauso für KI-gestützte Entwicklung. Firewalls versagen. Abhängigkeiten haben Schwachstellen. Menschen klicken falsch. Konfiguration driftet. Secrets landen an der falschen Stelle. Ein unerwarteter Input überschreitet eine Grenze, die niemand bedacht hat.

Wenn Teams die Sandbox als Strategie behandeln, gehen sie stillschweigend davon aus, dass eine Schicht immer exakt so funktioniert wie geplant.

Ernsthafte Systeme werden nicht so entworfen.

Sie gehen davon aus, dass einzelne Kontrollen ausfallen können, und begrenzen den Schaden.

Die Frage sollte deshalb nicht lauten:

Kann der Agent aus der Sandbox ausbrechen?

Die bessere Frage lautet:

Wenn irgendeine Grenze versagt, was kann der Agent dann erreichen, verändern, leaken oder auslösen?

Das ist Schadenradius-Denken.

Was Schadenradius bei Coding-Agenten bedeutet

In der Infrastruktur beschreibt der Schadenradius, wie viel Schaden ein einzelner Fehler verursachen kann.

Dasselbe Prinzip gilt für KI-Coding-Agenten.

Der Schadenradius eines Agenten ist die praktische Folge einer schlechten Anweisung, einer kompromittierten Abhängigkeit, einer Prompt Injection, einer falschen Freigabe, eines Tool-Bugs oder eines Modellmissverständnisses.

Er umfasst:

• welche Dateien der Agent lesen und schreiben kann;
• welche Befehle er ausführen kann;
• welche Umgebungsvariablen und Secrets er sehen kann;
• auf welche Repositories er Zugriff hat;
• welche MCP-Server oder internen Tools er aufrufen kann;
• welche externen Netzwerkziele erreichbar sind;
• welche Datenbanken, Logs, Tickets oder Cloud-Dienste er einsehen kann;
• welche Änderungen von lokaler Arbeit in gemeinsame Branches, Staging oder Produktion gelangen können.

Der sicherste Agent ist nicht immer der Agent mit den wenigsten Fähigkeiten.

Der sicherste Agent ist der, dessen Fähigkeiten zur Aufgabe passen und dessen Fehler begrenzt bleiben.

Die gefährliche Zwischenzone

Viele Teams landen in einer riskanten Zwischenzone.

Sie verbieten KI-Coding-Tools nicht. Sie integrieren sie aber auch nicht sauber in ihr Engineering-System.

Also läuft der Agent in der normalen Entwicklungsumgebung eines Entwicklers: mit normalem Repository-Checkout, normaler .env-Datei, normaler Shell, normalem Paketmanager, normaler Browser-Session und den lokal installierten Tools.

Das wirkt pragmatisch.

So beginnt Adoption oft.

Aber es erzeugt Unklarheit. Niemand weiß genau, was der Agent sehen kann. Niemand kann leicht erklären, welche Befehle ausgeführt wurden. Niemand weiß, ob ein Prompt, eine Abhängigkeit, eine Extension, ein MCP-Tool oder ein kopierter Terminal-Auszug etwas Sensibles offengelegt hat. Niemand hat entschieden, ob der Agent Authentifizierung, Billing, Migrationen, Deployment-Konfiguration, Kundendaten oder Produktionslogs anfassen darf.

Diese Unklarheit ist das Problem.

Für einen Prototyp kann sie akzeptabel sein.

Für ein ernsthaftes Produkt ist sie kein Betriebsmodell.

Die richtige Frage für Gründer und CTOs

Die strategische Frage lautet nicht: “Welches KI-Coding-Tool ist am sichersten?”

Tools sind wichtig, aber diese Frage ist zu eng.

Die bessere Frage lautet:

Welche Arbeit erlauben wir Agenten, und welches System umgibt diese Arbeit?

Ein Gründer, der mit einem Agenten einen Wegwerf-Prototyp baut, hat ein Risikoprofil. Ein CTO, der Agenten in eine produktionsnahe SaaS-Codebasis lässt, hat ein anderes. Ein Mittelstandsteam, das Agenten mit internen Tools, Kundenprozessen, ERP-Daten oder operativen Dashboards verbindet, hat wieder ein anderes.

Je wertvoller das System, desto klarer müssen die Grenzen sein.

Das bedeutet nicht, langsam zu arbeiten.

Es bedeutet, Beschleunigung dort zu nutzen, wo Fehler billig, sichtbar und umkehrbar sind, und die Bereiche zu schützen, in denen Fehler teuer werden.

Praktisches Schadenradius-Design

Gute Kontrollen müssen nicht theatralisch sein. Sie müssen konkret sein.

Für die meisten Teams beginnt es mit wenigen Entscheidungen.

1. Prototyp, Entwicklung und Produktion trennen

Ein Agent, der einen Prototyp baut, sollte nicht denselben Zugriff haben wie ein Agent in einem produktionsnahen Repository.

Nutzen Sie getrennte Umgebungen. Nutzen Sie Testdaten oder anonymisierte Daten. Halten Sie Produktions-Credentials aus lokalen Agent-Kontexten heraus. Behandeln Sie auch Staging als kontrolliertes System, nicht als Ablagefläche für riskante Experimente.

Das ist besonders in deutschen und europäischen Kontexten wichtig, weil Kunden-, Mitarbeiter-, Vertrags- und Betriebsdaten rechtliche und wirtschaftliche Verpflichtungen auslösen können.

Das am einfachsten zu schützende Secret ist das, das der Agent nie bekommt.

2. Repository- und Dateizugriff begrenzen

Nicht jede Aufgabe braucht die ganze Codebasis.

Eine UI-Textänderung braucht keinen Zugriff auf Billing-Logik. Eine Testaufgabe braucht keine Deployment-Credentials. Ein Refactoring in einem Paket braucht nicht automatisch die Erlaubnis, Konfiguration im ganzen Repository umzuschreiben.

Kleine Aufgaben, enge Arbeitsverzeichnisse, klare ausgeschlossene Pfade und Branch-basierte Workflows reduzieren den Schaden, wenn ein Agent falsch abbiegt.

Das verbessert auch die Qualität. Agenten arbeiten besser, wenn Aufgabe und Kontext begrenzt sind.

3. Terminal-Ausführung als privilegiert behandeln

Shell-Zugriff ist kein kleines Feature.

Ein Agent, der Befehle ausführen kann, kann Dateien prüfen, Pakete installieren, Zustand verändern, Services starten, Skripte aufrufen, Umgebungsvariablen lesen und manchmal Systeme erreichen, die das Team gar nicht freigeben wollte.

Teams sollten entscheiden, welche Befehle Agenten automatisch ausführen dürfen, welche menschliche Freigabe brauchen und welche in Agent-Workflows gar nicht erlaubt sind.

Paketinstallation verdient besondere Aufmerksamkeit. Eine vom Agenten hinzugefügte Abhängigkeit ist trotzdem eine Abhängigkeit, für die das Unternehmen verantwortlich ist.

4. Secrets langweilig und schwer erreichbar machen

KI-Agenten sollten API-Keys, Datenbank-URLs, Cloud-Tokens, OAuth-Secrets, SSH-Keys oder Produktions-Credentials nicht beiläufig sehen.

Dafür reicht es nicht, Menschen zur Vorsicht zu ermahnen.

Nutzen Sie getrennte Entwicklungs-Credentials. Bevorzugen Sie kurzlebige Tokens. Halten Sie echte Kundendaten standardmäßig aus agentensichtbaren Kontexten heraus. Scannen Sie auf Secrets. Kopieren Sie keine Logs oder .env-Dateien in Prompts. Prüfen Sie jede Agent-Änderung genau, die Konfiguration, Authentifizierung, Autorisierung oder Integrationscode betrifft.

Das Ziel ist nicht Paranoia.

Das Ziel ist, zu verhindern, dass Bequemlichkeit zur stillen Credential-Policy wird.

5. Review und CI als Kontrollfläche behalten

KI-Coding macht Pull Requests, Tests, statische Analyse, Dependency Checks und menschliches Review nicht überflüssig.

Es macht sie wichtiger.

Wenn Agenten schneller mehr Änderungen erzeugen, wird das Review-System der Ort, an dem Produkturteil, Architektur, Sicherheit und Betriebszuverlässigkeit geschützt werden.

Das Review sollte nicht nur fragen, ob der Code läuft.

Es sollte fragen:

• Gehört diese Änderung an diese Stelle im System?
• Hat der Agent eine neue Abhängigkeit oder einen externen Aufruf eingeführt?
• Wurden Berechtigungen oder Validierung geschwächt?
• Wurden Migrationen, Auth, Billing oder Deployment-Pfade berührt?
• Prüfen die Tests wirklich das gewünschte Verhalten?
• Lässt sich die Änderung sauber zurückrollen?

Hier zählt weiterhin erfahrenes Engineering-Urteil.

6. Protokollieren, was Agenten getan haben

Wenn ein Agent das System verändert, sollte das Team nachvollziehen können, was passiert ist.

Mindestens hilfreich sind Aufzeichnungen über Aufgaben-Prompts, geänderte Dateien, ausgeführte Befehle, aufgerufene Tools, hinzugefügte Abhängigkeiten und Review-Entscheidungen. Bei sensiblen Systemen sollte das mit normalem Audit Logging und Incident Response zusammenspielen.

Es geht nicht darum, dem Modell Schuld zu geben.

Es geht darum, das Liefersystem professionell zu betreiben.

Wenn drei Wochen später ein Fehler auftaucht, ist “die KI hat irgendwas gemacht” keine brauchbare Incident-Notiz.

7. Festlegen, welche Bereiche menschlich geführt bleiben

Manche Aufgaben eignen sich gut für starke KI-Unterstützung:

• Tests;
• Dokumentation;
• kleine UI-Änderungen;
• interne Tools;
• Migrationsgerüste;
• wiederkehrende Refactorings;
• Codebase-Erkundung;
• Entwurfsimplementierungen hinter Review.

Andere Bereiche brauchen engere Kontrolle:

• Authentifizierung;
• Autorisierung;
• Mandantentrennung;
• Zahlungen;
• Zugriff auf Produktionsdaten;
• irreversible Operationen;
• Deployment-Pipelines;
• Sicherheitskonfiguration;
• rechtlich oder compliance-relevante Workflows.

Die Antwort ist nicht, dass Agenten hier nie helfen dürfen.

Die Antwort ist, dass sie dort nicht beiläufig handeln sollten.

Warum das Architektur ist

Es ist verführerisch, KI-Coding-Sicherheit als Tool-Checkliste zu behandeln.

Den richtigen Editor wählen. Die richtige Einstellung aktivieren. Die richtigen Prompts freigeben. Den richtigen Scanner hinzufügen.

Das hilft, reicht aber nicht.

Es ist ein Architekturthema, weil es in Wahrheit um Systemgrenzen und Verantwortung geht.

Wo darf der Agent handeln? Welche Daten gehören in seinen Kontext? Welche Tools darf er aufrufen? Welche Aktionen sind umkehrbar? Welche Änderungen brauchen Review? Welche Umgebungen sind vertrauenswürdig? Welche Teile des Systems müssen stabil bleiben, selbst wenn ein Entwicklertool unerwartet reagiert?

Das sind Architekturfragen.

Bei McDougall Digital denken wir so über KI-gestützte Softwareentwicklung: Das Ziel ist nicht, Agenten maximal mächtig zu machen. Das Ziel ist, sie in einem Liefersystem nützlich zu machen, das das Produkt weiterhin schützt.

Tempo ohne Grenzen ist keine Reife.

Begrenztes Tempo ist es.

Der praktische Schluss

KI-Coding-Agenten sind nützlich.

Für viele Teams machen sie Entwicklung bereits schneller, Dokumentation leichter, Tests vollständiger und Codebase-Erkundung weniger mühsam.

Aber am meisten profitieren nicht die Teams, die einfach die meisten Agenten mit den breitesten Berechtigungen laufen lassen.

Am meisten profitieren die Teams, die den Workflow darum herum gestalten:

• begrenzte Aufgaben;
• isolierte Umgebungen;
• Least-Privilege-Zugriff;
• saubere Branch- und Review-Prozesse;
• verlässliche CI;
• sinnvolle Dependency-Regeln;
• geschützte Secrets;
• Logs und Nachvollziehbarkeit;
• klare menschliche Verantwortung für Produkt- und Architekturentscheidungen.

So wird aus KI-Coding nicht nur eine beeindruckende Demo, sondern eine verlässliche Engineering-Fähigkeit.

Wo McDougall Digital helfen kann

McDougall Digital unterstützt Teams dabei, KI-gestützte Entwicklung einzuführen, ohne die Kontrolle über das Produkt zu verlieren.

Das kann bedeuten: bestehende Codebasis und Delivery-Workflow prüfen, sichere Agent-Anwendungsfälle definieren, Prototyp- und Produktionsumgebungen trennen, CI- und Review-Gates schärfen, Architekturregeln für Agenten dokumentieren, Secret-Exposition reduzieren oder ein praktisches Betriebsmodell für KI-gestützte Lieferung entwerfen.

Das Ziel ist nicht, Teams auszubremsen.

Es geht darum, Geschwindigkeit nutzbar zu machen.

Wenn Ihr Team bereits mit Claude Code, Cursor, Codex, Lovable, Replit Agent, Devin oder MCP-basierten Tools experimentiert, ist die nächste nützliche Frage einfach:

Wie weit kann sich ein einzelner Agentenfehler ausbreiten?

Wenn diese Frage klar beantwortet ist, wird KI-gestützte Entwicklung deutlich vertrauenswürdiger.