Sicherheitsverantwortliche sehen bei KI-Code eine wachsende Sichtbarkeitslücke

Das Grundproblem ist laut den Diskutierenden nicht neu, wird durch generative KI aber deutlich verschärft. Code entsteht heute aus vielen Quellen: über aktivierte KI-Funktionen in genehmigten SaaS-Werkzeugen ohne Prüfung durch die IT, über Skripte und Automatisierungen außerhalb freigegebener Umgebungen oder über Agenten, die einzelne Teams ohne zentrale Sichtbarkeit aufsetzen. Nach Einschätzung der Runde geschieht das meist nicht böswillig, sondern aus dem Wunsch heraus, effizienter zu arbeiten.

Matt Muller von Datadog formulierte das drastisch: „Mitarbeitende, die ihre Arbeit erledigen wollen, sind mit Abstand die hartnäckigsten und erfolgreichsten APTs.“ Wenn Beschäftigte glaubten, dass ihnen Zugriff auf das neueste Modell bei der Arbeit helfe, würden sie einen Weg finden. Selbst offensichtliche Werkzeuge zu verbieten, verlagere das Verhalten laut Muller oft nur in weniger sichtbare Kanäle – die Sichtbarkeit sinke, das Risiko aber nicht.

Indu Sajeev, frühere CISO von ASOS, hält deshalb wenig von einem rein papier- oder richtlinienbasierten Governance-Ansatz. „Ich glaube nicht, dass das eine papierbasierte, richtlinienbasierte Governance-Schicht sein kann. Es muss etwas sein, das codifiziert ist und auf Ebene kritischer Infrastruktur kontinuierlich läuft“, sagte sie. Bevor anspruchsvollere Kontrollen greifen könnten, sei jedoch zunächst Grundlagenarbeit nötig, ergänzte Mario Villatoro von Jamf. Entscheidend sei eine saubere Datenklassifizierung: Wer nur von „sensiblen Daten“ spreche, ohne diese genauer zu kennzeichnen, schaffe keine belastbare Grundlage für nachgelagerte Kontrollen wie Zugriffsrechte, Agenten-Governance oder Audit-Trails.

Datadog setzt laut Muller darauf, dass das Sicherheitsteam als zentraler Anbieter von Werkzeugen auftritt, nicht als Instanz, die deren Nutzung überwacht. Ein wirksamer Ansatz sei ein interner Marktplatz für Werkzeuge wie Claude-Fähigkeiten. Die Bitte an Entwicklungsteams laute dann lediglich, Rückmeldung zu geben und so die Funktionen zu verbessern. Das Ziel sei, alle KI-Nutzung durch einen sichtbaren, geregelten Kanal zu lenken, statt Beschäftigte in Schattenstrukturen zu drängen.

Bei ASOS adressierte Sajeev das Problem mit einem Register für Anwendungsfälle. KI-Agenten würden dort eher wie Infrastruktur-Ressourcen als wie einfache Software-Funktionen behandelt. Dadurch lasse sich nachvollziehen, für welchen konkreten Zweck ein Agent erstellt wurde und welche menschliche Identität dahintersteht. Das Register dient laut Sajeev nicht nur als Inventar, sondern macht Verantwortlichkeit rückverfolgbar und legt zugleich Schwächen in der Dateninfrastruktur offen, die sonst oft erst im Störfall sichtbar würden.

Jamf verfolgt laut Villatoro einen anderen Schwerpunkt: Befähigung statt Beschränkung. Mitarbeitende sollten die richtigen Werkzeuge, Schulungen und Regeln für zulässige Nutzung erhalten, bevor sie sich selbst Alternativen suchen. Fehle diese Unterstützung, suchten Beschäftigte nach Wegen, sich selbst zu helfen – und genau daraus entstünden Probleme.

Muller verwies zudem auf unerwartete Verhaltensweisen von KI-Werkzeugen. Wenn Claude Code erkenne, dass es auf etwas nicht zugreifen könne, gebe es Szenarien, in denen es „faktisch versucht, seine eigene Malware zu bauen, um die benötigten Zugangsdaten auszuleiten“. Statt die Nutzung solcher Werkzeuge pauschal zu verbieten, sei es aus seiner Sicht wertvoller, in technische Kontrollen zu investieren, die den Zugriff auf diese Zugangsdaten von vornherein verhindern.

Selbst dort, wo Organisationen bewusste Entscheidungen über KI-Werkzeuge treffen, fehlen laut Muller und Sajeev oft ausreichend feingranulare Kontrollen. Muller nannte als Beispiel die Freigabe von Claude für Gmail: Heute lasse sich zwar der Zugriff insgesamt erlauben, nicht aber präzise auf E-Mails mit einem bestimmten Kennzeichen begrenzen. Sajeev sieht darüber hinaus eine strukturelle Lücke: Zero Trust funktioniere bei menschlichen Identitäten gut, „überall sonst“ gebe es aber noch Defizite. Muller formulierte den Wunsch nach granulareren OAuth-Berechtigungen direkt an Anbieter wie Google.