Was früher unter „Schatten-KI" verstanden wurde — Mitarbeiter, die vertrauliche Inhalte in ChatGPT einfügen —, hat sich laut Red Access verschoben. Heute bauen Beschäftigte vollständige Anwendungen mit KI, binden sie an Produktivsysteme an und stellen sie öffentlich ins Netz. Aus einem Prompt ist ein Produkt geworden, und mit ihm wanderte die Angriffsfläche.
Die Beispiele aus dem Bericht sind alltäglich: Eine Marketing-Managerin baut einen Kampagnen-Tracker und verbindet ihn mit dem BI-Werkzeug, in dem die echten Zahlen liegen. Ein Operations-Manager erstellt ein Lieferantenformular und koppelt es an das Ticketsystem. Solche Anwendungen werden an freigegebene Produktivsysteme angeschlossen — CRMs, ERPs, Ticketing-Werkzeuge, BI-Plattformen — und oft mit genau den Zugriffskontrollen veröffentlicht, die der Erbauer zufällig konfiguriert hat. Häufig mit gar keinen.
Red Access betont, dass die Beteiligten nicht böswillig handeln: Es seien kompetente Mitarbeiter, die reale Probleme schneller lösen, als ihre Organisation es könnte, und die genau das tun, wozu die Plattformen einladen. Auch die Plattformen seien keine Schurken. Was nicht Schritt gehalten habe, seien die technischen und verhaltensbezogenen Leitplanken für das, was nach dem Bau passiert.
Der Bericht grenzt das Phänomen von klassischer Schatten-IT ab. Dort lagen Daten zwar bei einem nicht freigegebenen SaaS-Anbieter, doch Identität, Audit-Protokolle und eine Governance-Ebene existierten zumindest. Bei „Shadow Builders" sei das umgekehrt: Die Anwendung ist maßgeschneidert, die Daten werden individuell geladen, die Integrationen sind direkte Verbindungen zu Systemen, und das Ergebnis liegt oft im offenen Internet. Die zugrunde liegende Plattform mag auditiert sein — die darauf gebaute Anwendung ist es nicht.
Nach Darstellung von Red Access greifen die üblichen Sicherheitswerkzeuge hier nicht ineinander. EDR sehe den Browser-Prozess, nicht den Bau darin, und nur auf verwalteten Geräten — persönliche Laptops, Auftragnehmer-Rechner und BYOD-Geräte blieben unsichtbar. DLP überwache definierte Kanäle, könne aber eine per API direkt von Cloud zu Cloud laufende Verbindung nicht erfassen. CASB sei für Schatten-IT gebaut und könne eine unbegrenzte Zahl individueller Anwendungen auf den Subdomains einer Plattform kaum vom Anbieter selbst unterscheiden. Firewall und SSE wiederum sähen den Verkehr zur Plattform-Domain, aber nicht den Anwendungskontext. Keines dieser Werkzeuge versage, so Red Access — die Kategorie sitze schlicht in den Lücken zwischen den Schichten.
Das Unternehmen argumentiert, dass jeder Schritt — der Bau, die OAuth-Freigabe, die Datenbewegung und die Veröffentlichung per Klick — ein Ereignis auf der Sitzungsebene sei. Eine dort positionierte Kontrolle sehe daher den gesamten Bauweg, zurechenbar auf eine konkrete Person und Anwendungsinstanz, unabhängig von Browser, Netzwerkpfad oder Geräteeigentum.
Als ersten organisatorischen Schritt empfiehlt Red Access, Mitarbeiter direkt zu fragen, was sie gebaut haben — als Inventarisierung, nicht als Audit. Anschließend solle man erfassen, mit welchen Systemen jede Anwendung verbunden ist und ob sie öffentlich erreichbar ist; die öffentliche Erreichbarkeit sei kurzfristig das aussagekräftigste Signal. Drittens solle ein freigegebener Weg mit benannten Plattformen, zulässigen Datenkategorien und einem Mindeststandard für Authentifizierung geschaffen werden. Und schließlich sei das keine einmalige Bestandsaufnahme: Neue Anwendungen entstünden laufend, weshalb kontinuierliche Erkennung nötig sei.