Zum Inhalt springen
← Alle Artikel

Shadow AI: warum Verbote bei AI-Coding-Tools scheitern

12. Okt. 2026 · Lessons Learned · 5 min

·Von Dimitri Pisarev

Javier Garza schult Entwickler in AI-Security, bei Snyk. In einer Session, die der AI Engineer Channel am Sonntag veröffentlicht hat, nennt er die Zahl, die er garantiert: Verbiete AI-Coding-Tools, und 80 bis 90 Prozent der Entwickler finden einen Weg daran vorbei. Die Worklogs auf dieser Seite entstehen selbst mit diesen Werkzeugen, deshalb ist die Zahl mehr als eine Anekdote.

Was behauptet der Snyk-Workshop wirklich?#

Garza ist Staff Developer Advocate bei Snyk, normalerweise läuft dieses Material als dreistündiges Seminar. Der AI Engineer Channel hat am Sonntag einen zweistündigen Schnitt veröffentlicht unter dem Titel AI Security Engineer Foundations, sechs Module über die OWASP Top 10 für LLMs, Threat Modeling, Supply-Chain-Risiken, Shadow AI, MCP-Server-Security und Vibe Coding. Snyk hostet die Kursseite mit einem Zertifikat am Ende.

Die Behauptung, die für jedes Engineering-Team zählt, sitzt im Shadow-AI-Modul. Sein Szenario: Eine Firma verbietet alle AI-Coding-Tools außer denen mit geprüften Policies. Seine Garantie, im Wortlaut der Session-Notizen: „You can install in companies as much as possible more rules to restrict people from nonsense, but if you don't teach people and don't teach them, they will get around anything.“ Achtzig bis neunzig Prozent finden den Weg drumherum, sagt er. Seine Konsequenz: Setze die Nutzung als vorhanden voraus und baue dafür.

Shadow AI hat Zahlen hinter der Garantie#

Er zitiert Umfragen, ohne sie beim Namen zu nennen. Behandle diese Zahlen also als seine Zahlen, nicht als gesicherte Forschung: 80 Prozent der Organisationen haben keine autorisierte Usage-Policy für AI, 60 Prozent der Beschäftigten nutzen nicht autorisierte AI-Tools, und die zweite Zahl setze er heute eher bei 80 Prozent an. Mehr als die Hälfte der Leute nutzt private Accounts für Arbeit, nach seiner Rechnung.

Das Bild, das er von Firmen zeichnet, die Tools verbieten, ist konkret. Beschäftigte stellen den privaten Laptop neben den Arbeitsrechner, starten den Coding-Assistenten dort und schicken sich die Ergebnisse selbst zu. Das Werkzeug verlässt das Gebäude und nimmt jeden Prompt mit.

Der Umweg ist die Schwachstelle#

Ein verbotenes Tool erzeugt zuerst ein Sichtbarkeitsproblem und dann ein Compliance-Problem. Ein sanktioniertes Werkzeug liegt im Inventar, produziert Logs und wird gescannt. Ein Tool, das am Verbot vorbeiläuft, produziert keins davon, während sein Code trotzdem in deinem Repository landet.

Zwei Supply-Chain-Zahlen der Session machen den Punkt. Er zitiert einen Scan von Agent-Skills von Dritten, den Textdateien, die Coding-Agents Aufgaben beibringen: 367 von 10.000 enthielten Schadsoftware. In einer von ihm erwähnten Umfrage hieß es, AI-Code-Completion gehöre zur Software-Supply-Chain, und rund 45 Prozent antworteten mit nein, während sie die Ausgabe direkt in die Codebasis einfügen. Zu dieser Ausgabe seine Behauptung: In über der Hälfte der Fälle trägt Code aus einem simplen Prompt mindestens fünf Schwachstellen. Als neueren Verwandten nennt er Paketnamen, die sich der Agent ausdenkt, und wer den Namen zuerst registriert, besitzt die Supply Chain, die danach kommt.

Ich schreibe täglich mit diesen Werkzeugen, und die Disziplin, die mich ehrlich hält, ist unspektakulär. Agent-Ausgabe ist ein ungeprüfter Pull Request, bis jemand den Diff gelesen hat. Eine Policy, die das Werkzeug aus den Büchern drängt, drängt den Diff-Review mit hinaus.

Wie Governance in einem kleinen Team aussieht#

Seine Gegenmaßnahmen brauchen keinen Einkauf. Behandle alles, was ein Modell liest oder schreibt, als nicht vertrauenswürdige Eingabe. Lege einen menschlichen Freigabeschritt vor destruktive Aktionen, er beschreibt sein eigenes Setup, in dem jeder Agent vor dem Löschen oder dem Mailversand in seinem Namen nachfragt. Führe eine Allowlist von Werkzeugen und Quellen und prüfe sie nach jedem Update neu, denn ein sauberer MCP-Server bleibt es bis zur nächsten Version nicht. Halte ein Inventar der AI-Assets, eine AI Bill of Materials in seiner Terminologie, und scanne es täglich, denn Modelle und Datensätze driften. Protokolliere, was Agents tun. Die meisten Leute richten gar kein Logging ein, sagt er, darum bleiben Nebenwirkungen unbemerkt, bis sie Vorfälle sind. Und Secrets: Viele Agent-Tools bringen keinen Secrets Manager mit, man klebt den API-Key also direkt in den Chat, wo er gespeichert wird.

Ein Verbot erzeugtEin Gate erzeugt
Schattennutzung ohne LogsWerkzeuge, die du scannen und auditen kannst
Review entfällt unter DruckReview ist im Workflow verankert
Keine Provenance im VorfallProvenance als Antwort

Das Interessante ist, was er nicht behauptet. Er sagt nie, dass die Werkzeuge sicher seien, und seine eigenen Supply-Chain-Zahlen sagen das Gegenteil. Die Behauptung ist schmaler: Regeln ohne Schulung scheitern, der Hebel ist Prozess um Werkzeuge, die du sehen kannst.

Sag Ja mit einem Gate#

Teams, die das gut hinbekommen, machen eines anders. Sie wählen einen sanktionierten Assistenten, bauen ihn in den Workflow ein und machen den sanktionierten Weg schneller als den Umweg. Das ist ein Rollout, und Rollout-Maschinerie vertraue ich für Produktfeatures schon: Diese Woche habe ich aufgeschrieben, wie meine Multi-Tenant-Plattform Capabilities hinter Tenant-Feature-Flags ausliefert. Erst das Gate, dann schrittweise öffnen, danach auditieren, und dasselbe Muster passt auf ein Coding-Tool. Diese Woche hat das Muster Hardware bekommen: Chainguard hat Agent-Workspaces veröffentlicht, die jedem Coding-Agent eine isolierte MicroVM mit eingespielten Credentials und einem vollständigen Befehls-Protokoll geben. Für ein Team, das fragt, was am Montag zu tun ist: Schreibe auf, welche Werkzeuge erlaubt sind, verankere die Liste in der Repository-Config, damit der Review sie sieht, und frage einmal im Quartal ab, welche Werkzeuge die Leute wirklich nutzen. Die Lücke zwischen beiden Listen ist die echte Sicherheitslage.

Modellverhalten braucht dieselbe Behandlung. OpenAI hat in sechs Misalignment-Reports Modelle dokumentiert, die Anweisungen in die eigenen Summaries schmuggelten und Daten erfanden, und der Fix war auch dort Prozess: Trace-Assertions, eine Allowlist für Hosts, ein Kill Switch. Garzas Garantie und diese Reports sind sich über die Form der Antwort einig, das eine über Leute, das andere über Modelle. Die Woche lieferte auch den regulatorischen Beleg: Indiens CERT-In hat Agents im Test dokumentiert, die an Live-Systeme kamen, über exponierte Zugangsdaten, die niemand rotiert hatte. Ein Verbot ist eine Policy-Datei. Governance ist eine Pipeline.