Von der Eingabe zum Produkt: Die Evolution des Shadow AI
Noch bis vor kurzem bedeutete Shadow AI im Unternehmenskontext vor allem eines: Mitarbeiter, die vertrauliche Daten in ChatGPT kopierten. Ärgerlich, aber mit entsprechenden DLP-Richtlinien (Data Loss Prevention) weitgehend in den Griff zu bekommen. Doch die KI-Revolution ist einen entscheidenden Schritt weitergegangen. Statt nur Prompts einzugeben, bauen Mitarbeiter nun komplette Anwendungen mithilfe von KI – sogenanntes „Vibe Coding“ –, verknüpfen diese mit produktiven Systemen und veröffentlichen sie im offenen Internet. IT und Security? Nicht im Raum.
Der Risiko-Fokus hat sich verschoben: Vom Prompt zum Produkt.
Die Zahlen des „Shadow Builders“-Berichts
Eine aktuelle Untersuchung von Red Access („The Shadow Builders“), die unter anderem von WIRED und VentureBeat aufgegriffen wurde, offenbart das Ausmaß des Problems. Die Forscher identifizierten über 380.000 öffentlich zugängliche Web-Assets auf den führenden Vibe-Coding-Plattformen. Etwa 5.000 davon konnten eindeutig dem Unternehmensumfeld zugeordnet werden. Bei mehr als 2.000 dieser Apps handelte es sich um sensible Betriebs-, Unternehmens- oder Personendaten – ungeschützt im offenen Web. Oftmals waren sie ohne Zugriffsbeschränkungen deployt, mit Standard-Adminrechten für jeden, der die URL kannte. Branchenübergreifend, auf allen sechs Kontinenten. Und das alles, während die betroffenen Unternehmen ihre Compliance-Audits bestanden.
Warum traditionelle Security-Stacks hier blind sind
Die naheliegende Reaktion eines CISO: Die eigenen Werkzeuge checken. EDR läuft, DLP ist konfiguriert, CASB ist lizenziert, Firewalls und SSE sind aktiv. Doch das Problem liegt genau in den Lücken zwischen diesen Systemen.
- EDR (Endpoint Detection and Response) sieht nur den Browser-Prozess, nicht das, was innerhalb des Browsers gebaut wird. Für den Endpoint-Agenten sieht Vibe Coding aus wie normales Surfen.
- DLP überwacht bekannte Kanäle. Es erkennt, wenn jemand Daten in einen Chatbot pastet, aber nicht, wenn eine Vibe-Coded-App per API programmatisch Daten aus einem BI-Tool zieht – völlig am Endgerät vorbei.
- CASB wurde für klassisches Shadow IT gebaut: für SaaS-Anbieter mit festen Identitäten. Eine Flut von Custom-Apps auf den Subdomains einer Vibe-Coding-Plattform wird von CASB schlichtweg als ein einziger, genehmigter SaaS-Anbieter gewertet.
- Firewalls und SSE sehen den Traffic zur Plattform, haben aber keinen Kontext für die einzelne Applikation. Zudem scheitern sie oft am Problem der nicht-gemanagten Geräte (BYOD, Contractor-Laptops).
Keines dieser Tools versagt im Kern. Die neue Bedrohungskategorie operiert schlicht in den Rissen, die zwischen den Architektur-Schichten klaffen.
Der feine Unterschied: Shadow IT vs. Shadow Builder
Klassisches Shadow IT war begrenzt. Wenn ein Team heimlich ein Trello-Abo abschloss, lagen die Daten zwar bei einem nicht sanktionierten Anbieter, aber es gab Identitäten, Audit-Logs und eine Governance-Oberfläche. Shadow Builder drehen das um: Die Applikation ist maßgeschneidert, die Daten individuell verknüpft, die Integration greift direkt in die produktiven Systeme (CRM, ERP). Die Plattform darunter mag auditierbar sein, die darauf gebaute App ist es nicht.
Die Erbauer sind dabei keine Böswilligen. Es sind kompetente Mitarbeiter, die echte Probleme schneller lösen, als es die offiziellen IT-Prozesse zulassen. Sie tun genau das, was die Plattformen ihnen suggerieren. Das Problem: Die Guardrails für die Zeit nach dem Build fehlen.
Journalistische Einordnung: Das Paradigma der Session-Sicherheit
Der Bericht von Red Access ist natürlich nicht ganz selbstlos – das Unternehmen positioniert damit seine eigene agentenlose „Session-Layer“-Sicherheitsplattform, die genau an diesem Punkt ansetzen soll. Doch unabhängig vom Marketing-Interesse des Autors ist die Diagnose brandaktuell und treffend.
Vibe Coding komprimiert Entwicklungszyklen von Monaten auf Stunden. Die Demokratisierung der Softwareentwicklung überholt die etablierten Governance-Prozesse. Da jeder Schritt des Vibe Codings – vom Build über die OAuth-Autorisierung bis zum Publish-Event – ein Browser-Event ist, muss die Kontrolle auch dort ansetzen: auf Session-Ebene. Nur so lässt sich der gesamte Lebenszyklus erfassen, unabhängig vom verwendeten Gerät.
Was Unternehmen jetzt tun können (ohne neues Tooling)
Bevor das nächste Budget für neue Sicherheitslösungen locker gemacht wird, empfiehlt der Bericht vier sofortige, rein prozessuale Schritte:
- Discovery durch Dialog: Fragt die Mitarbeiter direkt, was sie gebaut haben. Ein unternehmensweiter Aufruf („Wir inventarisieren nur, wir auditen nicht“) bringt mehr Transparenz als jede Policy.
- Mapping: Erfasst bei jeder genannten App, an welche Systeme sie angebunden ist (OAuth, API-Key?), ob sensible Daten fließen und ob sie öffentlich erreichbar ist.
- Sanktionierte Pfade etablieren: Gebt den Shadow Buildern einen sicheren Hafen. Definiert erlaubte Plattformen, Datenklassen und Mindestanforderungen an die Authentifizierung.
- Kontinuität akzeptieren: Vibe Coding ist kein einmaliges Phänomen. Was heute erfasst ist, ist morgen unvollständig. Das Inventar muss kontinuierlich wachsen.
Fazit: Vibe Coding ist gekommen, um zu bleiben. Die Plattformen werden ihre Defaults anpassen, aber die aktuelle Exposure ist real. Security-Teams müssen anerkennen, dass klassische Schutzschilde hier blind sind. Die Lösung beginnt nicht mit einem Tool-Kauf, sondern mit einer offenen Kommunikation mit den Mitarbeitern, die einfach nur effizient arbeiten wollen.
Quelle: The Hacker News
