Der Approval-Prompt ist nicht die Grenze

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

Die Benutzeroberflaeche ist nicht die Grenze.

Am Wochenende wurde auf X verstaerkt ueber ein Angriffsmuster namens SymJack diskutiert: eine Symlink-Hijack-Technik gegen KI-Coding-Agenten und CLIs. Die technischen Details gehoeren in Security-Analysen. Die wichtigere Lehre fuer Gruender, CTOs, Product Owner und Mittelstand-Teams ist breiter und praktischer.

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

Die wichtigere Frage lautet:

Auf welchen Pfad schreibt das Betriebssystem wirklich, und welche Autoritaet bekommt der Agent dadurch?

Das klingt klein. Ist es aber nicht.

Moderne Agenten koennen Repositories klonen, Code analysieren, Befehle ausfuehren, Dateien bearbeiten, Dependencies installieren, Konfiguration veraendern, MCP-Server anbinden und manchmal Aenderungen vorbereiten, die spaeter in CI/CD landen. Wenn ein boesartiges 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-gestuetzte 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

Fruehes AI Coding fuehlte 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 Autoritaet. Er konnte falsch liegen, aber er konnte nicht einfach lokale Konfiguration veraendern, ein Tool installieren oder ein anderes Projekt beeinflussen, solange der Mensch diese Schritte nicht ausfuehrte.

Diese Grenze wird duenner.

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 nuetzlich. Sie sehen mehr Kontext, machen Multi-File-Aenderungen, starten Tests, rufen Tools auf und arbeiten laenger an einer Aufgabe.

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

Er hat einen Ausfuehrungskontext.

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 Autoritaetsgrenze.

Das Problem mit Approval-Prompts

Approval-Prompts sollen Vertrauen schaffen.

Der Agent schlaegt 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, waehrend der tatsaechliche Schreibvorgang an einer anderen Stelle landet. Eine kopierte Datei kann scheinbar Dokumentation oder einen harmlosen Workspace-Pfad betreffen, waehrend das Betriebssystem einem Link zu einem Konfigurationspfad folgt. Wenn das Tool den Pfad vor der Freigabe nicht kanonisiert, erlaubt der Mensch eine Sache, waehrend das System eine andere tut.

Das ist in der Software-Sicherheit kein neues Konzept.

Path Traversal, Symlink Races, unsichere Archiv-Extraktion und irrefuehrende 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 gefaehrlich.

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.

Fuer ein serioeses 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 schuetzen Cloud-Credentials, Datenbanken, Payment-Systeme, Kundendaten und Deployment-Pipelines. Dann kommen KI-Coding-Agenten durch die Seitentuer: lokale Entwicklung.

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

In der Praxis sind Entwicklerumgebungen oft sehr sensibel.

Dort liegen haeufig:

• .env-Dateien fuer 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 fuer interne Tools;
• Zugriff auf mehrere Client-Repositories;
• Skripte, die Deployments oder Datenmigrationen ausloesen.

Fuer deutsche und europaeische Unternehmen ist das kommerziell und rechtlich relevant. Client-Projekte, Mitarbeiterdaten, operative Exporte und Integrations-Credentials liegen oft naeher an der Entwicklung, als man gerne zugibt.

Wenn ein KI-Agent dazu gebracht werden kann, seine eigene Konfiguration zu veraendern, ein Tool hinzuzufuegen, eine Startdatei zu aendern oder ausserhalb 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 Autoritaet liegt.

Repository-Vertrauen wird eine echte Entscheidung

Entwickler klonen staendig 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 ausfuehrt.

KI-Agenten veraendern dieses Modell.

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

Teams brauchen klarere Kategorien:

• vertrauenswuerdige interne Repositories;
• Client-Repositories mit vertraglichen Grenzen;
• Third-Party-Open-Source-Repositories;
• untrusted Reproduktionsfaelle;
• experimentell generierter Code;
• heruntergeladene Beispiele und Templates.

Diese Kategorien sollten veraendern, was ein Agent tun darf.

Ein Agent in einem vertrauenswuerdigen internen Service darf vielleicht Tests ausfuehren 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 Moeglichkeit, vertrauenswuerdige Tool-Einstellungen zu veraendern.

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

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

Was serioese Teams pruefen sollten

Die praktische Reaktion ist keine Panik.

Es ist ein kurzer Audit der echten Agent-Autoritaet.

1. Wo liegt die Agent-Konfiguration?

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

Dazu gehoeren 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 veraendern?
• Werden Aenderungen an diesen Dateien reviewed?
• Sind globale und projektbezogene Einstellungen getrennt?
• Gibt es einen sauberen Reset?

Wenn Agent-Konfiguration durch Projektinhalt veraendert werden kann, braucht das Team staerkere Grenzen.

2. Werden Pfade vor der Freigabe aufgeloest?

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

Fuer Agent-Tools bedeutet das: Symlinks und kanonische Pfade vor der Freigabe aufloesen, Workspace-Grenzen nach der Aufloesung erzwingen und Schreibvorgaenge ablehnen, die aus dem vorgesehenen Bereich ausbrechen.

Teams muessen nicht jeden Entwickler zum Filesystem-Security-Experten machen. Aber sie sollten Tools und Workflows waehlen, 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-Autoritaet geoeffnet werden wie Kernprodukte.

Nutzen Sie wegwerfbare Container, virtuelle Maschinen, isolierte Worktrees oder separate User-Accounts fuer untrusted Code. Halten Sie Secrets draussen. 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 schwerfaellig zu machen. Es geht darum, ein schlechtes Repository loeschen zu koennen, ohne sich zu fragen, was es sonst noch veraendert hat.

4. Welche Dateien sind auch ausserhalb 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-Aenderungen an solchen Pfaden sollten extra Review bekommen. Nicht weil Agenten einzigartig schlecht sind, sondern weil Geschwindigkeit die Chance erhoeht, dass eine riskante Aenderung wie Routine aussieht.

5. Kann das Team rekonstruieren, was passiert ist?

Wenn ein Agent Dateien veraendert, Befehle ausfuehrt, Dependencies installiert oder Konfiguration aendert, sollte das Team nachvollziehen koennen, was passiert ist.

Dazu gehoeren sinnvolle Logs: Aufgaben-Prompt, geaenderte Dateien, ausgefuehrte Befehle, genutzte Tools, hinzugefuegte Dependencies, betroffene Konfiguration und Review-Entscheidungen.

Das ist keine Buerokratie. Es ist Incident Response fuer KI-gestuetzte Arbeit.

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

Die Gruender- und CTO-Frage

Fuer Fuehrungsteams ist nicht die wichtigste Frage, ob ein bestimmter Exploit eine bestimmte Tool-Version heute betrifft.

Das aendert 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 ueberall dort, wo Sprache, Dateien, Tools, Credentials und Automatisierung zusammentreffen.

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

Sie werden Kontexte sauber trennen:

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

So behalten Teams die Geschwindigkeit, ohne jede Komfortfunktion in unsichtbare Autoritaet zu verwandeln.

Wie McDougall Digital helfen kann

Bei McDougall Digital ist genau das die Art von Thema, bei der architekturorientierte KI-Einfuehrung zaehlt.

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, ausfuehren und Tools aufrufen koennen;
• trusted und untrusted Repository-Workflows trennen;
• lokale und CI/CD-nahe Credential-Exposition pruefen;
• Pfad- und Workspace-Grenzen gestalten;
• Regeln fuer MCP-Server und Agent-Konfiguration definieren;
• Review-Gates fuer sensible Dateien einbauen;
• ein Betriebsmodell schaffen, dem Entwickler wirklich folgen koennen.

KI-Coding-Agenten sind nuetzlich. Richtig eingesetzt machen sie serioese Softwareteams schneller.

Aber der Approval-Prompt ist nicht die Grenze.

Die Grenze ist die Architektur darum herum.