KI-Coding sicher nutzen – ein vertrauenswürdiges Repository reicht nicht

Wer einen KI-Coding-Assistenten sicher nutzen will, sollte auch ein bekanntes Repository zunächst als unvertrauenswürdige Arbeitsumgebung behandeln. Der sichere Start kombiniert einen eingeschränkten Projektmodus, isolierte Befehlsausführung, minimale Toolrechte, getrennte Secrets und die manuelle Prüfung aller Änderungen.

Vertrauen gilt dabei nie pauschal für das gesamte Projekt. Ausführbare Projektdateien, dauerhafte Agentenanweisungen, Verbindungen zu externen Werkzeugen und Erweiterungen bilden vier eigenständige Kontrollflächen; jede muss geprüft und separat freigegeben werden.

1. Vier Vertrauensflächen getrennt inventarisieren

Quellcode und Abhängigkeiten sind nur ein Teil der Prüfung. Google Clouds Analyse vom 12. Mai 2026 gliedert die erweiterte Angriffsfläche danach, was Befehle ausführt, Agenten anweist, Verbindungen herstellt oder die Entwicklungsumgebung erweitert. Die Herkunft des Repositorys beantwortet daher noch nicht, was seine agentenlesbaren Dateien tatsächlich bewirken.

• Ausführen: Erfassen Sie Tasks, Build- und Installationsskripte, Debug-Konfigurationen, Container-Setups und Paket-Hooks. Prüfen Sie nicht nur den aufgerufenen Befehl, sondern auch nachgeladene Skripte, Arbeitsverzeichnisse und Umgebungsvariablen.
• Anweisen: Lesen Sie Agenten-, Prompt-, Regel- und Skill-Dateien vollständig. Auffällig sind Anweisungen, Schutzregeln zu umgehen, zusätzliche Dateien zu öffnen, Ergebnisse zu verbergen oder Informationen an externe Ziele zu übermitteln.
• Verbinden: Kontrollieren Sie MCP-Konfigurationen, Tooldefinitionen, Serveradressen, Proxys und übergebene Identitäten. Auch syntaktisch korrekte Einstellungen können Code, Prompts oder Zugangsdaten an einen unerwünschten Dienst leiten.
• Erweitern: Behandeln Sie IDE-Erweiterungen und Agenten-Plug-ins als Drittcode. Installationsquelle, Herausgeber, benötigte Berechtigungen und Update-Kanal müssen nachvollziehbar sein.

Dokumentieren Sie für jede Gruppe einen eigenen Prüfstatus. Ein unauffälliger Quellcode-Scan kann weder die Bedeutung einer natürlich formulierten Agentenanweisung noch einen ausgetauschten Tool-Endpunkt zuverlässig beurteilen.

2. Das Projekt ohne aktive Agentenrechte öffnen

Der erste Blick auf ein unbekanntes Projekt sollte keine Tasks, Debugger, Installationsschritte oder Agentenaktionen auslösen. Die Sicherheitsdokumentation von VS Code empfiehlt dafür Restricted Mode, die Prüfung aller Änderungen im Diff und sitzungsbezogene Freigaben; auf macOS und Linux einschließlich WSL2 kann die derzeit als Preview geführte Agent-Sandbox Datei- und Netzwerkzugriffe von Agentenbefehlen auf Betriebssystemebene begrenzen.

Herstellerübergreifend folgt daraus: erst passiv untersuchen, dann einzelne Fähigkeiten aktivieren. Nutzen Sie für den Beginn eine Wegwerfkopie, einen separaten Worktree oder einen Entwicklungscontainer ohne produktive Zugangsdaten. Ein Worktree trennt Änderungen vom aktiven Arbeitsstand, ist allein aber keine Sicherheitsgrenze; für nicht vertrauenswürdige Befehle braucht es zusätzlich eine echte Isolation.

Eine Sandbox begrenzt mögliche Folgen, entscheidet jedoch nicht, ob eine Instruktion, ein Tool oder eine Änderung legitim ist. Die ergänzenden Kontrollen hinter den Grenzen der Sandbox bleiben deshalb Teil derselben Baseline.

3. Werkzeuge und Verbindungen nach dem Minimalprinzip freigeben

Aktivieren Sie nur die Werkzeuge, Verzeichnisse und Netzwerkziele, die der konkrete Auftrag benötigt. Für eine lokale Refaktorierung sind in der Regel weder Schreibzugriff außerhalb des Projektordners noch Cloud-CLI, Deployment-Werkzeuge oder ein unbeschränkter Internetzugang erforderlich. Bevorzugen Sie Freigaben für eine einzelne Sitzung statt dauerhafter Berechtigungen auf Workspace- oder Benutzerebene.

Prüfen Sie jeden MCP-Server vor seinem ersten Start. Zum Inventar gehören Paketquelle und festgelegte Version, Startbefehl, erlaubte Dateipfade und Domains, angebotene Tools sowie die verwendete Identität. Ein vertraut klingender Servername sagt nichts darüber aus, ob das installierte Paket unverändert ist oder mit unnötig weitreichenden Rechten läuft.

Globale Auto-Freigaben gehören nicht in die Ausgangskonfiguration. Falls Automatisierung später nötig wird, beschränken Sie sie auf eng definierte, reversible Operationen. Zusammengesetzte Shell-Befehle, Paketinstallationen, neue Netzwerkziele, Git-Push und Infrastrukturänderungen sollten weiterhin eine verständliche Bestätigung mit vollständigem Befehl und erkennbarem Ziel verlangen.

4. Hooks, Erweiterungen und Secrets entkoppeln

Hooks sind ausführbare Automatisierung und nicht bloß Hinweise für das Modell. Die als Preview gekennzeichnete Hook-Dokumentation von VS Code beschreibt deterministische Befehle an festgelegten Punkten einer Agentensitzung und warnt davor, Hook-Skripte ohne manuelle Freigabe durch denselben Agenten verändern zu lassen, der sie anschließend ausführt.

Inventarisieren Sie Lebenszyklus-, Agenten-, Git- und Paketmanager-Hooks samt ihrer Skriptziele. Ein Hook kann riskante Toolaufrufe blockieren oder protokollieren; stammt seine Konfiguration jedoch aus dem ungeprüften Repository, ist er selbst Teil der zu kontrollierenden Ausführungsfläche. Sicherheits-Hooks sollten deshalb außerhalb des Agentenschreibbereichs liegen oder gegen automatische Änderungen geschützt sein.

Installieren Sie projektempfohlene Erweiterungen nicht gesammelt. Prüfen Sie jede Erweiterung separat und entfernen Sie nicht benötigte Komponenten. Für Plattformteams ist eine gepflegte Positivliste mit festgelegten Quellen und Freigabeverfahren besser überprüfbar als die automatische Übernahme sämtlicher Repository-Empfehlungen.

Secrets gehören weder in Projektdateien noch in Agentenanweisungen oder pauschal vererbte Sitzungsvariablen. Stellen Sie kurzlebige Zugangsdaten mit minimalem Scope ausschließlich dem benötigten Werkzeug über einen Secret Store bereit. Test- und Produktionsidentitäten sollten getrennt bleiben; produktive Kundendaten sowie administrative oder für Deployments geeignete Tokens sind für gewöhnliche Coding-Aufgaben nicht erforderlich.

5. Änderungen prüfen und Vertrauen widerrufbar halten

Behandeln Sie Agentenausgaben wie Änderungen eines neuen externen Mitwirkenden. Prüfen Sie den vollständigen Diff einschließlich versteckter Konfigurationsverzeichnisse, Lockfiles, CI-Dateien und gelöschter Schutzregeln. Besondere Aufmerksamkeit verdienen neue Netzwerkziele, verschleierte Befehle, gelockerte Berechtigungen, deaktivierte Tests und Zugriffe auf Secrets.

1. Öffnen Sie das Projekt eingeschränkt und inventarisieren Sie die vier Vertrauensflächen.
2. Führen Sie erste Prüfungen ohne produktive Zugangsdaten und ohne freien Netzwerkzugang aus.
3. Formulieren Sie einen kleinen, überprüfbaren Auftrag und aktivieren Sie nur die dafür erforderlichen Werkzeuge.
4. Kontrollieren Sie Toolaufrufe, Terminalbefehle und den gesamten Diff; eine erfolgreiche Testausgabe ersetzt diese Prüfung nicht.
5. Erweitern Sie Rechte nur bei konkretem Bedarf und entziehen Sie temporäre Freigaben nach der Sitzung.

Damit bleibt Vertrauen beobachtbar und rückholbar. Ein geprüftes Repository kann schrittweise mehr Rechte erhalten, doch diese Entscheidung erstreckt sich nicht automatisch auf einen neuen MCP-Server, eine geänderte Instruktionsdatei, einen Hook oder das nächste Erweiterungs-Update.

Lesen Sie auch:

• KI-Agenten sicher ausführen: Die Sandbox allein reicht nicht
• Claude kostenlos nutzen: Das Fünf-Stunden-Limit ist nicht die einzige Grenze
• PaperCut-Zero-Day aktiv ausgenutzt: Jetzt reicht ein normales Update nicht