Schatten-Code: Die Sicherheitsrisiken, die deutsche Unternehmen 2026 unbemerkt einkaufen

Im Git-Log eines meiner Projekte steht mein Name an einem Commit. Den Code dahinter habe ich nicht geschrieben. Ein KI-Agent hat ihn verfasst, ich habe ihn angestoßen und freigegeben. Er läuft trotzdem in meinem Namen in Produktion.

Das ist kein philosophisches Problem. Es ist der Kern einer Entwicklung, die gerade in deutschen Unternehmen Fahrt aufnimmt, und für die wir noch keine saubere Sprache haben. Ich nenne sie Schatten-Code.

Von Schatten-IT zu Schatten-Code

Schatten-IT kennen wir seit zwanzig Jahren. Mitarbeiter nutzen Dropbox, private Mail, einen USB-Stick, und die IT erfährt davon erst, wenn etwas schiefgeht. Das Muster ist ärgerlich, aber verstanden und beherrschbar.

Seit Anfang 2026 läuft eine zweite Stufe an. Diesmal trifft sie nicht die Datei-Ablage, sondern den Code der Kernsysteme. KI-Coding-Agenten schreiben Produktivcode, oft ohne Policy, ohne Review, ohne Audit-Trail. Die Kurzformel: Schatten-IT war Daten an der IT vorbei. Schatten-Code ist Produktivcode an der IT vorbei, der morgen euren Kunden ausliefert.

Dass es das Problem gibt, lässt sich an Zahlen ablesen. 79 Prozent der Organisationen haben keinen Überblick, welche KI-Agenten und angebundenen Tools in ihrer Umgebung laufen. Berichten zufolge sehen 98 Prozent eine KI-Nutzung, die nie freigegeben wurde. Im Mai hat sich eine US-Bank selbst beim Regulierer gemeldet, weil Kundendaten in einer nicht freigegebenen KI-App gelandet waren. Kein Hack, nur ein Mitarbeiter, der schneller arbeiten wollte. Gartner erwartet, dass bis Ende 2026 rund 40 Prozent der Enterprise-Apps task-spezifische Agenten enthalten. Die Werkzeuge sind also längst im Haus, bevor Security, Compliance und Einkauf Leitplanken ziehen konnten.

Vier Risiken, die unbemerkt mitgekauft werden

Erstens: IP-Abfluss über die Eingabeseite. Ein Coding-Agent ist nur so gut wie sein Kontext. Ein einfaches Beispiel: Ein Mitarbeiter bittet den Agenten, eine Schnittstelle zum Kundenregister zu bauen. Um zu antworten, liest der Agent zuerst das bestehende Modul. Dieses Modul enthält im Zweifel Datenbank-Schemas, Kundennamen aus Beispieldaten, einen API-Key aus einer schlecht bereinigten Test-Config. All das wird Teil des Prompts. Der Prompt wandert zum Modell-Anbieter, der Anbieter hat Log-Retention, und je nach Konfiguration lesen angebundene MCP-Server mit. Für die Geschäftsführung ist das kein IT-Thema, sondern eine Frage der Wettbewerbsfähigkeit. Wenn euer Produkt-Code in fremden Logs landet, baut ihn jemand anderes nach.

Zweitens: eine Lieferkette, die niemand auditiert hat. Agenten nutzen Werkzeuge: MCP-Server, Skills, ganze Marktplätze. Jedes davon ist ein neuer Upstream-Lieferant. Ein Beispiel, das harmloser klingt, als es ist: Ein Marketing-Mitarbeiter installiert einen MCP-Server aus einem Community-Marktplatz, um sein Blog-System anzubinden. Zwei Wochen später wird der Anbieter kompromittiert, und ein Update schickt bei jedem Prompt unbemerkt Kontext an eine externe URL. Niemand bemerkt es, weil der Traffic im normalen API-Rauschen untergeht. Dazu kommt die halluzinierte Abhängigkeit: Ein Agent importiert ein Paket, das es nicht gibt, weil er es sich zusammengereimt hat, und Angreifer registrieren genau diesen Namen, um beim nächsten Build mitzulaufen. Eure SBOM-Disziplin war gestern. Jetzt bräuchtet ihr eine Übersicht über Prompts und Kontextpfade, und die führt niemand.

Drittens: das Audit-Vakuum. Hier liegt mein Git-Log-Beispiel vom Anfang. Für Code-Reviews, das Vier-Augen-Prinzip und vor allem für BSI C5 in der 2026er Fassung und NIS2 müsst ihr die kontinuierliche Wirksamkeit eurer SDLC-Kontrollen nachweisen. Wer wann was gemacht hat, und dass ein zweites Augenpaar daraufgeschaut hat. Wenn der Urheber des Codes ein Prozess ist, den niemand zertifiziert hat, klafft eine Dokumentationslücke. Im Audit ist die Frage dann nicht "Wer hat das getippt?", sondern "Könnt ihr beweisen, dass ein Mensch es geprüft hat?". Bei vielen Teams lautet die ehrliche Antwort heute: noch nicht.

Viertens: die Geschwindigkeits-Asymmetrie. Wer heute mit einem Agenten in vier Stunden ein Feature baut, baut morgen in vier Stunden auch einen Exploit. Angreifer nutzen dieselben Werkzeuge wie ihr, nur ohne eure Review-Zyklen und Compliance-Prüfungen. Wenn ein Zero-Day bekannt wird, habt ihr nicht mehr Wochen zum Patchen, sondern Tage, manchmal Stunden. Der deutsche Mittelstand ist es gewohnt, dass Sicherheit eine Frage der Zeit ist: bestellen, umsetzen, testen, ausrollen. Ab 2026 ist Zeit keine neutrale Größe mehr. Wer nur die Produktionsseite beschleunigt und die Prüfseite nicht, öffnet eine Schere, die Angreifer aktiv nutzen.

Warum Verbote nicht helfen

Die erste Reaktion vieler Sicherheitsabteilungen ist das Verbot. Das ist verständlich und führt trotzdem in die Irre. Bei Schatten-IT hat das Verbot nie funktioniert, es hat die Nutzung nur in den privaten Laptop und das private Konto verschoben und der IT die letzte Sichtbarkeit genommen. Bei Schatten-Code wird es genauso laufen, nur dass diesmal Produktivcode betroffen ist. Wer verbietet, verliert. Was funktioniert, ist Enablement mit klaren Leitplanken.

Der Schatten-Code-Audit in drei Schritten

Erstens, Sichtbarkeit. Inventarisiert technisch, wer gerade Agenten nutzt, nicht per E-Mail-Umfrage. Die Signale liegen in jeder CI-Pipeline und jedem Git-Hosting: auffällige Commit-Muster, plötzliche Sprünge bei den Abhängigkeiten, Branches ohne Ticket-Bezug, eine Commit-Frequenz, die sich über Nacht verdoppelt. Das ist ein klassisches Observability-Problem auf Code-Ebene. Jemand muss die Daten nur abfragen.

Zweitens, Control. Eine Minimal-Policy statt großer Governance. Drei Fragen beantworten, nicht dreißig: Welche Tools sind erlaubt? Welche Datenklassen dürfen rein? Welche Freigabewege gelten? Ein schlechtes Dokument, das Orientierung gibt, ist besser als ein perfektes, das nie erscheint. Dass die Industrie hier nachzieht, zeigt ein aktuelles Beispiel: AWS hat Anfang Mai mit Trusted Remote Execution ein quelloffenes Werkzeug vorgestellt, das jede Systemoperation eines KI-generierten Skripts gegen eine Policy prüft, bevor sie ausgeführt wird. Die Technik kommt also. Die Policy dahinter müsst ihr selbst schreiben.

Drittens, Awareness. Baut Review-Kapazität auf. Das ist die eigentliche Engstelle. Nicht prompten, sondern prüfen. Investiert dort, wo ihr vorher in Entwickler investiert habt, und redet offen mit den Teams darüber, dass Prüfarbeit jetzt die wertvollere Zeit ist als Code-Produktion. Genau diese Umkehr fällt vielen am schwersten, weil sie dem alten Bild von Produktivität widerspricht.

Wer diese drei Schritte in neunzig Tagen angeht, ist dem Großteil des Mittelstands ein Jahr voraus. Und anders als bei großen Governance-Programmen skaliert der Audit nach unten: Schritt eins kann ein Dienstleister in einer Woche leisten, Schritt zwei ist eine Seite Policy, Schritt drei ist eine Gesprächsrunde mit den Teams.

Warum ich darüber schreibe

Mein Bezug zum Thema ist doppelt. Als Senior Cloud Security Architect berate ich Unternehmen zu AWS-Architekturen, BSI C5:2026 und NIS2. Gleichzeitig baue ich seit Januar selbst ein Cloud-Security-SaaS, konsequent mit KI-Coding-Agenten statt mit einem klassischen Entwicklerteam. Ich stehe also bei meinem eigenen Produkt vor genau den Fragen, die ich in Kundengesprächen stelle: Was gehört in die Policy? Wie dokumentiere ich Code, dessen Urheber nicht mehr eindeutig zuzuordnen ist? Wie passe ich Reviews an eine veränderte Entwicklungsrealität an? Ich spreche nicht als Mahner, sondern als jemand, der die Verführung von beiden Seiten kennt: die Versuchung, es einfach zu tun, und das mulmige Gefühl dabei.

Genau diese Lücke zwischen schneller Produktion und langsamer Prüfung schauen wir uns bei Tallence Cloud an. Nicht mit einem weiteren Tool, sondern mit der Frage, wie Sichtbarkeit, Control und Review-Disziplin in einer AWS-Umgebung zusammenkommen, die auch im Audit standhält.

Im September vertiefe ich das Thema in einem Vortrag beim Cybersecurity Meetup in Stuttgart. Bis dahin interessiert mich eure Sicht: Wie viele KI-Agenten laufen gerade in eurer Organisation, und hat jemand davon den vollständigen Überblick?