Coding-Agenten sind KI-Werkzeuge, die nicht nur Codevorschläge liefern, sondern eigenständig Aktionen auf dem Rechner ausführen: Dateien anlegen, ändern, löschen, Befehle starten, Abhängigkeiten installieren. Genau diese Eigenständigkeit macht sie im Entwicklungsalltag nützlich – und zugleich zu einem Sicherheitsthema, das über klassische Autovervollständigung hinausgeht.

Ein aktueller Ratgeber auf Golem.de beschreibt die Kernprobleme nüchtern: Lokale Coding-Agenten können selbstständig Dateien löschen, Zugangsdaten preisgeben und sich manipulieren lassen. Für Agenturen und IT-Abteilungen, die mit fremdem Quellcode und fremden Daten arbeiten, sind das keine theoretischen Randfälle, sondern Fragen der Sorgfaltspflicht.

Drei Risikofelder, die man auseinanderhalten sollte

Unbeabsichtigte Änderungen. Ein Agent, der ein Refactoring durchführen soll, interpretiert die Aufgabe eigenständig. Löscht er dabei Dateien oder überschreibt Konfigurationen, fällt das nicht zwingend sofort auf – besonders dann nicht, wenn viele Änderungen in einem Durchlauf entstehen und niemand sie einzeln prüft.

Preisgabe von Zugangsdaten. Entwicklungsumgebungen enthalten typischerweise mehr Geheimnisse, als einem im Alltag bewusst ist: Umgebungsvariablen, Datenbankzugänge, API-Schlüssel, SSH-Konfigurationen, Tokens in lokalen Konfigurationsdateien. Ein Agent, der Dateien liest, um Kontext aufzubauen, kann solche Inhalte verarbeiten und im schlechtesten Fall an einen externen Dienst weitergeben.

Manipulation von außen. Agenten verarbeiten Text – aus Repositories, Issues, Dokumentationen, Abhängigkeiten. Enthält dieser Text Anweisungen, kann das Modell sie als Auftrag interpretieren. Fachlich spricht man von Prompt Injection: Eingeschleuste Instruktionen in scheinbar harmlosen Daten lenken das Verhalten des Agenten um.

Warum das in Kundenprojekten schwerer wiegt

In einem privaten Nebenprojekt ist ein versehentlich gelöschtes Verzeichnis ärgerlich. In einem Kundenprojekt berührt derselbe Vorfall gleich mehrere Ebenen: Vertragspflichten zur Vertraulichkeit, Auftragsverarbeitung nach Datenschutzrecht, Nachweisbarkeit von Änderungen und nicht zuletzt das Vertrauen in die Lieferqualität.

Hinzu kommt ein praktisches Problem: Wenn unklar bleibt, welche Codezeilen von einem Menschen und welche von einem Agenten stammen, erschwert das die Fehlersuche und die Verantwortungszuordnung. Codequalität ist hier kein Stilthema, sondern eine Frage der Wartbarkeit über Jahre.

Leitplanken, die sich in der Praxis bewähren

Die wirksamsten Maßnahmen sind unspektakulär und organisatorischer Natur. Sie setzen weniger beim Modell an als bei der Umgebung, in der es arbeitet.

  • Rechte begrenzen: Ein Agent braucht Zugriff auf ein Projektverzeichnis, nicht auf das gesamte Benutzerkonto. Getrennte Arbeitsverzeichnisse, eigene Benutzer oder Container reduzieren den möglichen Schaden.
  • Geheimnisse trennen: Zugangsdaten gehören nicht in Dateien, die ein Agent routinemäßig liest. Secret-Management und kurzlebige Tokens begrenzen den Wert eines Abflusses.
  • Versionskontrolle konsequent nutzen: Jede Agentenänderung in einem eigenen Branch, nachvollziehbar in kleinen Commits. Was sich nicht als Diff prüfen lässt, sollte nicht in den Hauptzweig gelangen.
  • Review bleibt menschlich: Generierter Code wird wie fremder Code behandelt – inklusive Prüfung auf eingeschleppte Abhängigkeiten.
  • Produktivzugänge aussperren: Keine Verbindung zu Live-Datenbanken, Produktionssystemen oder Kundendaten aus der Agentenumgebung heraus.
  • Bestätigung bei kritischen Aktionen: Löschen, Installieren, Netzwerkzugriffe und Veröffentlichungen sollten eine ausdrückliche Freigabe erfordern statt automatisch zu laufen.

Die Frage nach dem Datenfluss

Vor dem Einsatz lohnt eine schlichte Inventur: Welche Daten verlassen den Rechner, wohin gehen sie, wie lange werden sie gespeichert, und wer darf sie zu welchen Zwecken verwenden? Auch ein lokal gestarteter Agent ist nicht automatisch ein lokal rechnender Agent – viele Werkzeuge senden Kontext an Modelle in der Cloud.

Für Projekte mit personenbezogenen Daten oder vertraulichen Geschäftsinformationen ist diese Unterscheidung zentral. Sie entscheidet darüber, ob ein Werkzeug überhaupt eingesetzt werden darf, ob eine Vereinbarung zur Auftragsverarbeitung nötig ist und ob Kundinnen und Kunden darüber informiert werden müssen.

Regeln schlagen Verbote

Ein pauschales Verbot ist selten tragfähig: Entwicklerinnen und Entwickler nutzen die Werkzeuge dann privat weiter, nur ohne Absprache. Produktiver ist eine schriftliche, knappe Richtlinie, die drei Dinge klärt: welche Werkzeuge freigegeben sind, in welchen Projekten sie verwendet werden dürfen, und welche Aktionen grundsätzlich eine menschliche Freigabe brauchen.

Dazu gehört auch ein Reaktionspfad für den Fall, dass doch etwas schiefgeht – etwa wenn der Verdacht besteht, dass ein Zugangsschlüssel abgeflossen ist. Schlüssel rotieren, Zugriffe prüfen, Vorfall dokumentieren: Das sollte geübt sein, bevor es gebraucht wird.

Einordnung für Web- und Softwareprojekte

Coding-Agenten verschieben die Grenze zwischen Vorschlag und Ausführung – und damit auch die Grenze der Verantwortung. Wer sie in Kundenprojekten einsetzt, sollte die technische Umgebung so gestalten, dass ein Fehlverhalten begrenzt bleibt, statt auf das Wohlverhalten des Modells zu vertrauen. Sandbox, Secret-Trennung, Versionskontrolle und menschliches Review sind dabei keine Bremsen, sondern die Voraussetzung dafür, dass der Produktivitätsgewinn überhaupt belastbar ist.

Quellen