Der Approval-Prompt ist nicht die Grenze

KI-Coding-Agenten bringen Softwareteams gerade eine alte Sicherheitslektion in neuer Form bei:

Die Benutzeroberfläche ist nicht die Grenze.

Am Wochenende wurde auf X verstärkt über ein Angriffsmuster namens SymJack diskutiert: eine Symlink-Hijack-Technik gegen KI-Coding-Agenten und CLIs. Die technischen Details gehören in Security-Analysen. Die wichtigere Lehre für Gründer, CTOs, Product Owner und Mittelstand-Teams ist breiter und praktischer.

Wenn ein KI-Coding-Agent um Erlaubnis bittet, eine Datei zu schreiben, zählt nicht nur, was der Prompt scheinbar anzeigt.

Die wichtigere Frage lautet:

Auf welchen Pfad schreibt das Betriebssystem wirklich, und welche Autorität bekommt der Agent dadurch?

Das klingt klein. Ist es aber nicht.

Moderne Agenten können Repositories klonen, Code analysieren, Befehle ausführen, Dateien bearbeiten, Dependencies installieren, Konfiguration verändern, MCP-Server anbinden und manchmal Änderungen vorbereiten, die später in CI/CD landen. Wenn ein bösartiges oder untrusted Repository eine Dateioperation harmlos aussehen lassen kann, obwohl sie auf einen sensibleren Pfad zeigt, ist der Approval-Prompt nur eine schwache Sicherheitsschicht.

Das Problem ist nicht, dass Entwickler unachtsam sind. Das Problem ist, dass KI-gestützte Entwicklung von “Assistent im Editor” zu “Akteur im Delivery-System” wird. Sobald das passiert, werden Filesystem-Semantik, Repository-Vertrauen, Konfigurationshoheit und Tool-Rechte zu Architekturentscheidungen.

Warum das jetzt wichtig ist

Frühes AI Coding fühlte sich meistens wie Textgenerierung an.

Man fragte nach einer Funktion. Das Modell schlug Code vor. Ein Mensch kopierte, passte an und commitete.

Dieser Workflow hatte Probleme, aber der Agent hatte meist wenig eigene Autorität. Er konnte falsch liegen, aber er konnte nicht einfach lokale Konfiguration verändern, ein Tool installieren oder ein anderes Projekt beeinflussen, solange der Mensch diese Schritte nicht ausführte.

Diese Grenze wird dünner.

Tools wie Claude Code, Cursor, Codex-artige CLIs, Copilot-Agenten, Gemini CLI, Replit-Agenten und verwandte Systeme sollen in echten Entwicklungsumgebungen handeln. Genau deshalb sind sie nützlich. Sie sehen mehr Kontext, machen Multi-File-Änderungen, starten Tests, rufen Tools auf und arbeiten länger an einer Aufgabe.

Je operativer der Agent wird, desto weniger sinnvoll ist es, ihn als “nur einen Prompt” zu betrachten.

Er hat einen Ausführungskontext.

Er hat Filesystem-Zugriff.

Er kann lokale Secrets in Reichweite haben.

Er kann Konfiguration sehen, die bestimmt, welche Tools er nutzen darf.

Er kann Zugriff auf Repositories haben, in denen Client-Code, Infrastrukturannahmen, Deployment-Skripte, API-Integrationen, Testdaten oder interne Dokumentation liegen.

In dieser Welt ist ein Pfad nicht nur Text in einem Dialog. Er ist eine Autoritätsgrenze.

Das Problem mit Approval-Prompts

Approval-Prompts sollen Vertrauen schaffen.

Der Agent schlägt eine Aktion vor. Der Mensch sieht sie. Der Mensch erlaubt oder verweigert sie.

Dieses Modell funktioniert nur, wenn der Prompt die echte Operation korrekt beschreibt.

Symlinks machen das subtil. Ein Pfad kann so aussehen, als liege er im Projekt, während der tatsächliche Schreibvorgang an einer anderen Stelle landet. Eine kopierte Datei kann scheinbar Dokumentation oder einen harmlosen Workspace-Pfad betreffen, während das Betriebssystem einem Link zu einem Konfigurationspfad folgt. Wenn das Tool den Pfad vor der Freigabe nicht kanonisiert, erlaubt der Mensch eine Sache, während das System eine andere tut.

Das ist in der Software-Sicherheit kein neues Konzept.

Path Traversal, Symlink Races, unsichere Archiv-Extraktion und irreführende Dateioperationen gibt es seit Langem. Neu ist die Geschwindigkeit, mit der KI-Coding-Agenten in Entwickler-Workflows eingebaut werden, oft von Teams, die lokale Entwicklungsumgebungen bisher nicht als klare Sicherheitsgrenze betrachtet haben.

Genau das ist gefährlich.

Der Agent muss nichts “wollen”. Er braucht nur eine Aufgabe, ein Repository, eine Dateioperation und die Erlaubnis zu handeln. Wenn das Trust-Modell des Tools schwach ist, kann Projektinhalt die Agent-Umgebung beeinflussen.

Für ein seriöses Produktteam ist das keine Frage der Tool-Vorliebe. Es ist eine Frage des Betriebsmodells.

Lokale Entwicklung ist nicht risikoarm

Viele Unternehmen sind bei Produktion vorsichtig.

Sie schützen Cloud-Credentials, Datenbanken, Payment-Systeme, Kundendaten und Deployment-Pipelines. Dann kommen KI-Coding-Agenten durch die Seitentür: lokale Entwicklung.

Das fühlt sich sicher an, weil es “nur eine Entwickler-Maschine” ist.

In der Praxis sind Entwicklerumgebungen oft sehr sensibel.

Dort liegen häufig:

• .env-Dateien für Staging oder interne Services;
• SSH-Keys oder Git-Credentials;
• Paket-Registry-Tokens;
• lokale Datenbank-Snapshots;
• Support-Exporte;
• Cloud-CLI-Sessions;
• Browser-Sessions;
• MCP-Server-Konfiguration;
• Zugangsdaten für interne Tools;
• Zugriff auf mehrere Client-Repositories;
• Skripte, die Deployments oder Datenmigrationen auslösen.

Für deutsche und europäische Unternehmen ist das kommerziell und rechtlich relevant. Client-Projekte, Mitarbeiterdaten, operative Exporte und Integrations-Credentials liegen oft näher an der Entwicklung, als man gerne zugibt.

Wenn ein KI-Agent dazu gebracht werden kann, seine eigene Konfiguration zu verändern, ein Tool hinzuzufügen, eine Startdatei zu ändern oder außerhalb des geplanten Repositories zu schreiben, wird die lokale Umgebung Teil der Angriffsfläche.

Deshalb reicht “wir lassen Agenten nicht auf Produktion deployen” nicht aus.

Produktion ist nicht der einzige Ort, an dem Autorität liegt.

Repository-Vertrauen wird eine echte Entscheidung

Entwickler klonen ständig Repositories.

Open-Source-Beispiele. Kundenprojekte. Vendor-Demos. Boilerplates. Reproduktions-Repos. Take-Home-Aufgaben. Interne Experimente. Code aus Tickets.

Vor agentischem Coding hatte ein unbekanntes Repository bereits Risiken. Aber das mentale Modell drehte sich meistens darum, ob der Mensch Code daraus ausführt.

KI-Agenten verändern dieses Modell.

Wenn der Agent Repository-Dateien als Kontext liest, Anweisungen in Projektdokumentation folgt, Dateioperationen ausführt, Setup-Befehle startet oder Konfiguration aktualisiert, ist das Repository kein passiver Input mehr. Es kann das Verhalten des Agenten beeinflussen.

Teams brauchen klarere Kategorien:

• vertrauenswürdige interne Repositories;
• Client-Repositories mit vertraglichen Grenzen;
• Third-Party-Open-Source-Repositories;
• untrusted Reproduktionsfälle;
• experimentell generierter Code;
• heruntergeladene Beispiele und Templates.

Diese Kategorien sollten verändern, was ein Agent tun darf.

Ein Agent in einem vertrauenswürdigen internen Service darf vielleicht Tests ausführen und Dateien in einem engen Workspace bearbeiten. Ein Agent in einem unbekannten Open-Source-Repo sollte in einer wegwerfbaren Umgebung laufen: ohne Secrets, ohne persistente Agent-Konfiguration, ohne breiten Zugriff auf das Home-Verzeichnis und ohne die Möglichkeit, vertrauenswürdige Tool-Einstellungen zu verändern.

Das klingt nach Aufwand, bis man es mit der Alternative vergleicht: Jedes geklonte Repository erbt stillschweigend die normale Autorität der Entwickler-Maschine.

Das ist keine Architektur. Das ist Bequemlichkeit, die sich als Architektur ausgibt.

Was seriöse Teams prüfen sollten

Die praktische Reaktion ist keine Panik.

Es ist ein kurzer Audit der echten Agent-Autorität.

1. Wo liegt die Agent-Konfiguration?

Finden Sie die Dateien und Verzeichnisse, die das Verhalten des Agenten steuern.

Dazu gehören CLI-Konfiguration, MCP-Server-Definitionen, Tool-Allowlists, Memory-Dateien, Hooks, Shell-Profile, Editor-Erweiterungen und projektbezogene Instruktionsdateien.

Dann fragen Sie:

• Kann ein Repository auf diese Pfade schreiben?
• Darf ein Agent sie im normalen Workflow verändern?
• Werden Änderungen an diesen Dateien reviewed?
• Sind globale und projektbezogene Einstellungen getrennt?
• Gibt es einen sauberen Reset?

Wenn Agent-Konfiguration durch Projektinhalt verändert werden kann, braucht das Team stärkere Grenzen.

2. Werden Pfade vor der Freigabe aufgelöst?

Ein brauchbarer Approval-Prompt sollte die echte Operation zeigen, nicht nur den scheinbaren Pfad.

Für Agent-Tools bedeutet das: Symlinks und kanonische Pfade vor der Freigabe auflösen, Workspace-Grenzen nach der Auflösung erzwingen und Schreibvorgänge ablehnen, die aus dem vorgesehenen Bereich ausbrechen.

Teams müssen nicht jeden Entwickler zum Filesystem-Security-Experten machen. Aber sie sollten Tools und Workflows wählen, die dieses Thema ernst nehmen.

Wenn ein Tool das echte Ziel nicht klar machen kann, sollte man Approvals als Hinweis betrachten, nicht als harte Grenze.

3. Laufen untrusted Repositories in wegwerfbaren Kontexten?

Unbekannte Repositories sollten nicht mit derselben Agent-Autorität geöffnet werden wie Kernprodukte.

Nutzen Sie wegwerfbare Container, virtuelle Maschinen, isolierte Worktrees oder separate User-Accounts für untrusted Code. Halten Sie Secrets draußen. Mounten Sie nur das notwendige Verzeichnis. Deaktivieren Sie persistente Tool-Konfiguration, wo es geht. Vermeiden Sie Zugriff auf das normale Home-Verzeichnis des Entwicklers.

Es geht nicht darum, Entwicklung schwerfällig zu machen. Es geht darum, ein schlechtes Repository löschen zu können, ohne sich zu fragen, was es sonst noch verändert hat.

4. Welche Dateien sind auch außerhalb von Produktion sensibel?

Viele sensible Dateien sehen nicht dramatisch aus.

Beispiele:

• .env und .env.local;
• CI-Workflow-Dateien;
• Paketmanager-Konfiguration;
• Deployment-Skripte;
• Auth- und Berechtigungscode;
• Billing-Logik;
• Migrationsskripte;
• MCP-Konfiguration;
• Shell-Startdateien;
• Editor-Settings;
• Credential-Helper-Konfiguration;
• generierte Client-SDKs mit Endpunkten oder Tokens.

Agent-Änderungen an solchen Pfaden sollten extra Review bekommen. Nicht weil Agenten einzigartig schlecht sind, sondern weil Geschwindigkeit die Chance erhöht, dass eine riskante Änderung wie Routine aussieht.

5. Kann das Team rekonstruieren, was passiert ist?

Wenn ein Agent Dateien verändert, Befehle ausführt, Dependencies installiert oder Konfiguration ändert, sollte das Team nachvollziehen können, was passiert ist.

Dazu gehören sinnvolle Logs: Aufgaben-Prompt, geänderte Dateien, ausgeführte Befehle, genutzte Tools, hinzugefügte Dependencies, betroffene Konfiguration und Review-Entscheidungen.

Das ist keine Bürokratie. Es ist Incident Response für KI-gestützte Arbeit.

Wenn etwas Seltsames passiert, ist “der Agent hat irgendwas gemacht” keine Diagnose.

Die Gründer- und CTO-Frage

Für Führungsteams ist nicht die wichtigste Frage, ob ein bestimmter Exploit eine bestimmte Tool-Version heute betrifft.

Das ändert sich schnell.

Die dauerhafte Frage lautet:

Wo erlauben wir KI-Agenten, Projektinhalt in Systemhandlung zu verwandeln?

Dort liegt die Grenze.

Sie erscheint in lokaler Entwicklung. Sie erscheint in CI/CD. Sie erscheint in Support-Tools. Sie erscheint in internen Admin-Systemen. Sie erscheint überall dort, wo Sprache, Dateien, Tools, Credentials und Automatisierung zusammentreffen.

Die Unternehmen, die am meisten von KI-gestützter Entwicklung profitieren, werden nicht einfach nur “ja” oder “nein” zu Agenten sagen.

Sie werden Kontexte sauber trennen:

• schnelle, risikoarme Räume für Experimente;
• begrenzte Entwicklungsworkflows für Produktcode;
• reviewed Wege in gemeinsame Branches;
• schmale Schnittstellen zu CI/CD;
• strenge Behandlung von Secrets und Konfiguration;
• klare Verantwortung für Agent-Tooling.

So behalten Teams die Geschwindigkeit, ohne jede Komfortfunktion in unsichtbare Autorität zu verwandeln.

Wie McDougall Digital helfen kann

Bei McDougall Digital ist genau das die Art von Thema, bei der architekturorientierte KI-Einführung zählt.

Das Ziel ist nicht, Teams mit theoretischen Risikodokumenten auszubremsen. Das Ziel ist, den schnellen Weg sicherer und klarer zu machen:

• erfassen, wo Agenten lesen, schreiben, ausführen und Tools aufrufen können;
• trusted und untrusted Repository-Workflows trennen;
• lokale und CI/CD-nahe Credential-Exposition prüfen;
• Pfad- und Workspace-Grenzen gestalten;
• Regeln für MCP-Server und Agent-Konfiguration definieren;
• Review-Gates für sensible Dateien einbauen;
• ein Betriebsmodell schaffen, dem Entwickler wirklich folgen können.

KI-Coding-Agenten sind nützlich. Richtig eingesetzt machen sie seriöse Softwareteams schneller.

Aber der Approval-Prompt ist nicht die Grenze.

Die Grenze ist die Architektur darum herum.