Unternehmen sind bei zwei Dritteln ihrer KI-Angriffsfläche blind, warnt Snyk
Snyk hat dem KI-Risiko in Unternehmen eine drastische Zahl gegeben: Fast zwei Drittel der relevanten Angriffsfläche können außerhalb des direkten Blickfelds von Sicherheitsteams liegen. Die über Google News verbreitete Warnung richtet den Fokus auf Agenten, Plugins, Datensätze und Datenpipelines, die im Arbeitsalltag miteinander verbunden sind. Diese Komponenten vermehren sich, wenn Unternehmen KI-Experimente in die Produktion überführen.
Die Zahl stammt von Snyk und nicht aus einem unabhängigen Audit des gesamten Unternehmensmarkts. Die zugrunde liegende Analyse nutzt anonymisierte Informationen aus mehr als 500 mit Snyk Evo verbundenen Unternehmensumgebungen. Diese Unterscheidung ist wichtig. Die Daten bieten Einblick in teilnehmende Umgebungen, während die weitergehende Behauptung weiterhin eine Validierung über andere Plattformen und Branchen hinweg erfordert.
Trotz dieser Einschränkung beschreibt Snyk ein Problem, das über die Telemetrie eines einzelnen Anbieters hinausgeht. Untersuchungen der Cloud Security Alliance ergaben, dass 68 % der befragten Organisationen KI-Agentenaktionen nicht eindeutig von menschlichen Aktivitäten unterscheiden konnten. OWASP hat prompt injection, übermäßige Berechtigungen und unkontrollierte Handlungsautonomie separat als wesentliche Anwendungsrisiken dokumentiert.
Der zentrale Konflikt lautet daher nicht KI-Einführung gegen Widerstand. Es geht um schnelle, dezentrale Bereitstellung gegenüber Sicherheitssystemen, die auf bekannten Anwendungen, menschlichen Identitäten und stabilen Inventaren aufbauen. Unternehmen autorisieren zunehmend mehr Software, zu schlussfolgern und zu handeln, während sie zugleich weniger Gewissheit darüber haben, was mit ihren Daten verbunden ist.
Diese Lücke setzt Sicherheitsteams unter Druck, betrifft aber auch Entwickler, Plattformingenieure, Beschaffungsverantwortliche und Fachbereichsverantwortliche. Jede Gruppe kann eine KI-Abhängigkeit einführen. Nur wenige Organisationen verfügen über ein System, das die daraus entstehende Kette von Modell über Plugin, Identität, Datensatz und API bis zur Produktionsaktion abbilden kann.
Warum die Snyk-Warnung Google News erreichte
Snyks wichtigste Aussage ist nicht, dass KI neue Schwachstellen schafft. Sie lautet vielmehr, dass Unternehmen die Systeme, die diese erzeugen, nicht zuverlässig sehen können.
Snyk stellte im Februar 2026 seine AI Security Fabric als Ebene vor, die Softwareentwicklung und agentische Systeme übergreift. Das Unternehmen erklärte, sein Ansatz verbinde Sichtbarkeit, Prävention und Governance über den gesamten Softwareentwicklungszyklus hinweg.
Diese Produktankündigung enthielt Erkenntnisse aus Snyks Studie State of Agentic AI Adoption 2026. Nach Angaben des Unternehmens umfasste die Analyse anonymisierte Einblicke aus mehr als 500 Evo-Unternehmensumgebungen. Snyk erklärte, jedes eingesetzte KI-Modell sei mit fast dreimal so vielen verborgenen Komponenten verbunden, darunter Datensätze und Tools von Drittanbietern.
Die Kernbehauptung geht über diese Beobachtung hinaus. Snyk zufolge liegt ungefähr zwei Drittel des KI-Risikos in Unternehmen unterhalb der sichtbarsten Modellebene. Der verdeckte Teil umfasst Agententools, Plugins, verbundene Repositories, externe Dienste und Datenpipelines, die Beschäftigte während der Entwicklung oder im Arbeitsalltag anbinden.
Diese Komponenten sind nicht automatisch bösartig. Ein Plugin kann lediglich ein Dokument abrufen, eine interne API aufrufen oder eine genehmigte Nachricht versenden. Das Sicherheitsproblem entsteht durch das Zusammenspiel von Komponente, ihren Berechtigungen, ihren Eingabequellen und ihrer Fähigkeit, nachgelagerte Aktionen auszulösen.
Ein reines Modellinventar kann diese Beziehungen nicht erfassen. Zwei Teams können dasselbe Modell über unterschiedliche Agenten mit völlig verschiedenen Risikoprofilen nutzen. Ein Agent kann öffentliche Dokumente zusammenfassen. Ein anderer kann Quellcode lesen, Kundendaten abfragen und Änderungen in Produktionssysteme schreiben.
Deshalb verdient die Geschichte mehr als die vertraute Warnung vor Beschäftigten, die nicht genehmigte Chatbots verwenden. Schatten-KI umfasst heute eingebettete Funktionen in genehmigter Software, lokal bereitgestellte Modelle, Agenten-Frameworks, Browsererweiterungen, Automatisierungsdienste und Maschinenidentitäten. Manche gelangen über formelle Beschaffung ins Unternehmen. Andere tauchen auf, wenn ein Mitarbeiter noch ein Tool verbindet, um eine Aufgabe abzuschließen.
Google News verschafft dieser Aussage einen breiten Vertriebskanal, aber Aggregation bestätigt die zugrunde liegende Zahl nicht. Leser sollten die Zwei-Drittel-Schätzung als Anbieterergebnis betrachten, das auf umgebungsbezogenen Daten von Snyk-Kunden beruht. Die stärkere Schlussfolgerung stützt sich auf bestätigende Belege: Unternehmen haben Schwierigkeiten, Agentenverhalten, Berechtigungen und Komponentenabhängigkeiten zu inventarisieren.
Diese Unterscheidung verhindert, dass die Analyse zu Produktmarketing wird. Snyks präzise marktweite Schätzung bleibt überprüfbar. Das Sichtbarkeitsproblem selbst wird bereits durch mehrere unabhängige und standardorientierte Quellen gestützt.
Die KI-Angriffsfläche ist keine Anwendungsliste mehr
Die praktische Angriffsfläche verhält sich heute wie ein sich wandelnder Graph, in dem Modelle, Identitäten, Tools und Datenspeicher durch ihre Verbindungen Risiken erzeugen.
Traditionelle Anwendungssicherheit beginnt mit einem relativ stabilen Objekt. Ein Team verantwortet eine Anwendung, pflegt ihr Repository, verfolgt Abhängigkeiten und stellt sie über bekannte Infrastruktur bereit. Sicherheitstools können Code, Pakete, Container-Images, Cloud-Konfigurationen und exponierte Endpunkte prüfen.
KI-native Systeme fügen mehr bewegliche Teile hinzu. Snyks Analyse von KI-nativen Anwendungen beschreibt eine Lieferkette, die vortrainierte Modelle, Embeddings, Agenten von Drittanbietern, Datensätze und externe Dienste umfassen kann. Jede Komponente kann sich unabhängig vom Quellcode der Anwendung verändern.
Ein Embedding ist eine numerische Repräsentation, mit der die Bedeutung von Inhalten verglichen wird. Eine Vektordatenbank kann Millionen dieser Repräsentationen für den Abruf speichern. Sind Berechtigungen oder Quellenkennzeichnungen falsch, kann ein Agent Informationen abrufen, auf die sein Nutzer niemals Zugriff haben sollte.
Retrieval-augmented generation, häufig zu RAG abgekürzt, stellt einem Modell ausgewählte Dokumente oder Datensätze bereit, bevor es eine Antwort erzeugt. RAG kann die Genauigkeit verbessern, schafft aber auch eine weitere Vertrauensgrenze. Die Abrufschicht muss entscheiden, welche Quellen der Agent durchsuchen darf und welche Inhalte sie zurückgeben soll.
Tools schaffen eine folgenschwerere Grenze. Ein Agent, der mit E-Mail, Versionsverwaltung, Cloud-Infrastruktur oder einer Kundendatenbank verbunden ist, kann über die bloße Texterzeugung hinausgehen. Je nach den von Entwicklern erteilten Berechtigungen kann er Informationen lesen, schreiben, ausführen, genehmigen oder übertragen.
Dadurch entsteht ein Missverhältnis zu Sicherheitsinventaren, die rund um beschaffte Anwendungen organisiert sind. Ein Unternehmen kann den Modellanbieter und das Agenten-Framework genehmigt haben. Dennoch kann ihm eine vollständige Aufzeichnung jedes Tool-Endpunkts, Servicekontos, Datensatzes, Prompt-Templates oder Plugins fehlen, das nach der Bereitstellung angebunden wurde.
Die Kette kann sich auch ohne ein traditionelles Release verändern. Ein Modellanbieter kann sein Verhalten aktualisieren. Ein Drittanbieter-Tool kann eine Funktion hinzufügen. Ein Datensatz kann neue Dokumente erhalten. Ein Nutzer kann einen OAuth-Bereich erweitern, der bestimmt, worauf eine Anwendung über delegierte Autorisierung zugreifen kann.
Diese Veränderungen sind wichtig, weil Risiken von Kombinationen abhängen. Ein Zusammenfassungsagent mit schreibgeschütztem Zugriff hat einen begrenzten Schadensradius. Erhält derselbe Agent die Berechtigung, E-Mails zu senden, Dateien zu bearbeiten und einen unbeschränkten Web-Endpunkt aufzurufen, kann eine manipulierte Eingabe zu einem völlig anderen Ergebnis führen.
Die Angriffsfläche umfasst daher mehr als Schwachstellen im Code. Sie beinhaltet übermäßige Berechtigungen, vergifteten Kontext, offengelegte Zugangsdaten, unsichere Ausgabehandhabung, schwache Genehmigungsregeln und unvollständige Aktionsprotokolle. Mehrere dieser Probleme bleiben für Scanner unsichtbar, die nur Quelldateien oder bekannte Softwarepakete prüfen.
Für Engineering-Teams wird Dokumentation zu einem Teil des Kontrollsystems. Eine durchsuchbare Aufzeichnung von Architekturentscheidungen, genehmigten Tools, Berechtigungsbereichen und Incident-Erkenntnissen hilft Teams, Beziehungen zu erkennen, die einzelne Dashboards übersehen. Eine strukturierte Engineering-Wissensdatenbank kann diese Arbeit unterstützen, ersetzt jedoch kein Sicherheitsmonitoring.
Die übergeordnete Lehre ist einfach. Ein KI-System kann nicht als einzelner Modell-Endpunkt gesteuert werden. Es muss als vernetzte Anwendung behandelt werden, deren Daten, Tools, Identitäten und Aktionen während des gesamten Betriebs sichtbar bleiben.
Agentische KI setzt Identitätskontrollen unter Druck
Der am schnellsten wachsende blinde Fleck liegt dort, wo autonome Software Berechtigungen übernimmt, die für menschliche Nutzer konzipiert wurden.
Die Cloud Security Alliance veröffentlichte im März 2026 eine Untersuchung zu Agentenidentitäten. Ihre Umfrage ergab, dass 73 % der Organisationen erwarteten, KI-Agenten würden innerhalb des folgenden Jahres unverzichtbar werden. Dennoch konnten 68 % Aktionen von Agenten nicht eindeutig von denen von Menschen unterscheiden.
Die Ähnlichkeit zwischen dieser 68-%-Zahl und Snyks Warnung von ungefähr zwei Dritteln ist auffällig, doch die Zahlen messen unterschiedliche Dinge. Snyk behandelt verborgene Komponenten und Risiken in KI-Umgebungen. Die Umfrage der Cloud Security Alliance untersucht Identitätszuordnung und Zugriffsmanagement.
Zusammen legen sie dieselbe strukturelle Schwäche offen. Organisationen gewähren Softwareidentitäten schneller Zugriff auf Geschäftssysteme, als sie ihre Authentifizierungs-, Autorisierungs- und Monitoring-Praktiken aktualisieren.
Eine Maschinenidentität ist ein von Software statt von einer Person verwendetes Zugangsmittel. Sie kann die Form eines API-Schlüssels, Servicekontos, Zertifikats, einer Workload-Identität oder eines OAuth-Tokens annehmen. Agenten sind auf diese Zugangsdaten angewiesen, um auf Daten zuzugreifen und Aktionen auszuführen.
Systeme für menschliche Identitäten gehen in der Regel davon aus, dass sich eine Person anmeldet, eine definierte Rolle erhält und Aktivitäten erzeugt, die diesem Konto zugeordnet sind. Agenten verkomplizieren dieses Modell. Ein Agent kann für mehrere Nutzer handeln, mehrere Tools aufrufen und innerhalb von Sekunden eine Kette maschinell erzeugter Vorgänge erstellen.
Die Zuordnung wird besonders schwierig, wenn ein Agent ein gemeinsames Servicekonto verwendet. Protokolle können zeigen, dass das Konto einen Datensatz geändert oder eine Datei heruntergeladen hat. Sie identifizieren möglicherweise nicht die Mitarbeiteranfrage, Modellentscheidung, das abgerufene Dokument oder den Plugin-Aufruf, die die Aktion verursacht haben.
Das ist nicht nur ein Auditproblem. Schwache Zuordnung erschwert die Eindämmung von Vorfällen. Ein Sicherheitsteam kann das richtige Zugangsmittel nicht zuverlässig widerrufen, wenn es nicht weiß, welcher Agent, Nutzer oder Workflow verdächtige Aktivitäten ausgelöst hat.
Überprivilegierter Zugriff erhöht den Schaden. Ein Tool, das lediglich Nachrichten zusammenfassen soll, kann die Berechtigung erhalten, sie zu senden oder zu löschen. Ein Codeassistent kann Schreibzugriff auf mehrere Repositories erhalten, obwohl er nur ein Projekt prüfen muss.
OWASP bezeichnet diesen Zustand als excessive agency. Die Leitlinien benennen übermäßige Funktionalität, Berechtigungen und Autonomie als Ursachen. OWASP empfiehlt, verfügbare Tools zu begrenzen, Berechtigungen einzugrenzen, Aktionen im Kontext des Nutzers auszuführen und für Vorgänge mit hoher Auswirkung eine Genehmigung zu verlangen.
Diese Kontrollen ähneln ausgereiften Zero-Trust-Praktiken. Jede Anfrage sollte anhand einer spezifischen Identität, einer definierten Autorisierung und des aktuellen Kontexts bewertet werden. Das Modell sollte nicht selbst entscheiden, ob ein Vorgang zulässig ist.
Der Agent benötigt außerdem eine eigene Identität, die von seinem menschlichen Betreiber getrennt ist. Protokolle sollten die Beziehung zwischen der Anfrage des Nutzers, der Agenteninstanz, dem ausgewählten Tool, den verwendeten Zugangsdaten und der daraus resultierenden Aktion festhalten. Ohne diese Kette können Unternehmen enorme Mengen an Telemetriedaten sammeln und dennoch im Dunkeln tappen.
Hier setzt die Einführung von KI die Sicherheitsarchitektur unter Druck. Fachbereiche wollen Assistenten, die wiederholte Freigaben beseitigen und mehrstufige Aufgaben erledigen. Sicherheitsteams brauchen Kontrollpunkte, eng begrenzte Berechtigungen und nachvollziehbare Entscheidungen. Werden alle Kontrollpunkte entfernt, steigt zwar die Geschwindigkeit, doch zugleich vergrößert sich der mögliche Schadensradius einer falschen oder manipulierten Aktion.
Dieser Konflikt lässt sich nicht durch vollständige Autonomie oder ein Verbot von Agenten lösen. Unternehmen benötigen unterschiedliche Autonomiestufen für unterschiedliche Folgen. Das Erstellen einer Zusammenfassung kann automatisiert bleiben. Das Versenden von Geldern, Löschen von Datensätzen, Ändern von Produktionsinfrastruktur oder Offenlegen geschützter Daten sollte stärkere Kontrollen erfordern.
Der eigentliche Zielkonflikt lautet: Geschwindigkeit gegen überprüfbare Kontrolle
Unternehmen gewinnen an Wert, wenn Agenten Systemgrenzen überschreiten, doch jede zusätzliche Verbindung erschwert die Überprüfung ihres Verhaltens.
Agentische KI ist für Unternehmen attraktiv, weil sie getrennte Schritte zu einem einzigen Workflow verbinden kann. Ein Support-Agent könnte ein Ticket lesen, die Kontohistorie abrufen, die Dringlichkeit klassifizieren, eine Antwort vorschlagen und den Kundendatensatz aktualisieren. Diese Abfolge kann den manuellen Abstimmungsaufwand verringern.
Dieselbe Abfolge enthält mehrere Sicherheitsgrenzen. Das Ticket kann nicht vertrauenswürdigen Text enthalten. Die Kontohistorie kann geschützte Daten umfassen. Das Modell kann eine unsichere Tool-Anweisung erzeugen. Das Kundensystem kann ein Update mit dauerhaften Folgen akzeptieren.
Prompt Injection macht diesen Zielkonflikt greifbar. Von Prompt Injection spricht man, wenn präparierte Inhalte verändern, wie ein Modell Anweisungen befolgt. Diese Inhalte können direkt von einem Nutzer oder indirekt von einer Webseite, einem Dokument, einer E-Mail, einem Repository oder einem abgerufenen Datensatz stammen.
Eine herkömmliche Anwendung trennt Befehle und Daten durch strikte Syntax- und Zugriffskontrollen. Sprachmodelle verarbeiten beides als Tokens innerhalb eines Kontexts. Dieses Design erschwert es, zu garantieren, dass ein Modell externen Text stets als nicht vertrauenswürdige Daten und nicht als Anweisung behandelt.
Die aktuellen Empfehlungen von OWASP besagen, dass keine narrensichere Methode zur Verhinderung von Prompt Injection bekannt ist. Empfohlen werden Verhaltensbeschränkungen, die Validierung erwarteter Ausgabeformate, das Filtern von Ein- und Ausgaben sowie die Begrenzung der dem Modell verfügbaren Berechtigungen.
Diese Gegenmaßnahmen verringern die Auswirkungen, schaffen jedoch keine Gewissheit. Ein Agent, der nur eine eng abgegrenzte Dokumentensammlung lesen kann, birgt weniger Gefahr als einer, der Shell-Befehle ausführen kann. Ein menschlicher Freigabeschritt kann verdächtige Aktionen abfangen, aber nur, wenn der Prüfer genügend Kontext erhält, um eine fundierte Entscheidung zu treffen.
Jede Schutzmaßnahme steht unter Geschwindigkeitsdruck. Teams könnten umfassende Zugriffe gewähren, um wiederholte Integrationsarbeit zu vermeiden. Sie könnten gemeinsame Zugangsdaten verwenden, weil eine nutzerspezifische Autorisierung länger dauert. Sie könnten Freigabeaufforderungen unterdrücken, nachdem Nutzer über Reibungsverluste geklagt haben.
Damit wird der Kernkonflikt zu einem Abwägen zwischen Bereitstellungsgeschwindigkeit und überprüfbarer Kontrolle. Snyk argumentiert, dass Sicherheit kontinuierlich werden muss, weil sich KI-Systeme zu schnell für gelegentliche Prüfungen verändern. Das kommerzielle Interesse des Unternehmens ist offensichtlich, da es Produkte verkauft, die genau für diese Anforderung positioniert sind.
Käufer sollten daher die Diagnose von der vorgeschlagenen Plattform trennen. Eine einheitliche Sicherheitsebene könnte die Sichtbarkeit verbessern, doch kein Anbieter hat nachgewiesen, dass ein einzelnes Produkt jedes Modell, jede lokale Bereitstellung, jedes Browser-Tool, jeden Datensatz, jede Identität und jede externe Integration in einem großen Unternehmen beobachten kann.
Aussagen zur Abdeckung hängen von Integrationen und Telemetrie ab. Ein genehmigtes Cloud-Modell lässt sich möglicherweise leicht erkennen. Ein lokal gehostetes Modell auf dem Arbeitsplatz eines Entwicklers hingegen nicht. Eine KI-Funktion innerhalb eines vertrauten Softwarepakets kann Aktivitäten erzeugen, die wie gewöhnlicher Anwendungsverkehr aussehen.
Verschlüsselte Verbindungen und Datenschutzvorschriften bringen weitere Grenzen mit sich. Die Überwachung von Prompts oder abgerufenen Dokumenten kann sensible Mitarbeiter- und Kundendaten offenlegen. Sicherheitsteams benötigen genügend Kontext, um Missbrauch zu erkennen, ohne ein zweites Repository vertraulicher Informationen aufzubauen.
Regionale Datenvorschriften fügen eine weitere Einschränkung hinzu. Ein multinationales Unternehmen kann möglicherweise nicht alle Protokolle von KI-Interaktionen zentralisieren. Es benötigt womöglich lokale Verarbeitung, selektive Metadaten, Aufbewahrungskontrollen und unterschiedliche Überwachungsrichtlinien für verschiedene Rechtsräume.
Diese Komplikationen entkräften Snyks Warnung nicht. Sie stärken deren Kernpunkt und stellen zugleich jede einfache Lösung infrage. Sichtbarkeit ist notwendig, doch Sichtbarkeit selbst verursacht Design-, Datenschutz- und Betriebskosten.
Was die Zwei-Drittel-Behauptung nicht beweist
Snyks Daten weisen auf eine erhebliche Governance-Lücke hin, belegen jedoch nicht, dass zwei Drittel jeder Unternehmensumgebung kompromittiert oder ausnutzbar sind.
Die wichtigste Einschränkung betrifft die Stichprobe. Snyk beschreibt anonymisierte Erkenntnisse aus mehr als 500 Enterprise-Evo-Umgebungen. Organisationen, die diese Umgebung nutzen, können sich hinsichtlich Größe, Softwarepraktiken, KI-Reife oder Sicherheitsprioritäten vom breiteren Markt unterscheiden.
Das Unternehmen hat öffentlich nicht nachgewiesen, dass seine Stichprobe jede Branche oder geografische Region repräsentiert. Es hat außerdem einen kommerziellen Grund, das Problem in einer Weise zu definieren, die eine breitere Sicherheitsabdeckung begünstigt. Keiner der beiden Punkte macht die Daten falsch, doch beide erfordern eine sorgfältige Einordnung der Quelle.
„Risiko“ ist zudem weiter gefasst als „Schwachstelle“. Eine verborgene Komponente kann unverwaltet oder unzureichend inventarisiert sein, ohne einen ausnutzbaren Fehler zu enthalten. Gefährlich wird sie in Kombination mit schwachen Berechtigungen, sensiblen Daten, unsicheren Eingaben oder der Fähigkeit, folgenschwere Aktionen auszuführen.
Ebenso bedeutet „zwei Drittel“ nicht, dass Sicherheitsteams exakt ein Drittel jeder Umgebung sehen. Die Schätzung fasst Muster in beobachteten Umgebungen zusammen. Einzelne Organisationen können eine deutlich bessere oder schlechtere Abdeckung haben.
Der Begriff „Angriffsfläche“ kann unterschiedliche Probleme zusätzlich verwischen. Er kann internetexponierte Assets, interne APIs, Softwareabhängigkeiten, Agenten-Tools, Datenflüsse, Identitäten und Modellverhalten umfassen. Verschiedene Anbieter zählen diese Elemente unterschiedlich.
Unabhängige Messungen erfordern gemeinsame Definitionen. Forschende müssen zwischen bekannten und unbekannten Assets, erreichbaren und inaktiven Komponenten sowie theoretischer Exposition und nachgewiesenen Angriffspfaden unterscheiden. Ohne diese Unterscheidungen erregen große Prozentwerte Aufmerksamkeit, bieten aber nur begrenzte operative Orientierung.
NIST bietet mit seinem AI Risk Framework eine neutralere Grundlage. Das Framework strukturiert die Arbeit rund um das Steuern, Abbilden, Messen und Managen von KI-Risiken. Es betont zudem, dass Risikomanagement während des gesamten Systemlebenszyklus fortgeführt werden sollte.
Das Abbilden ist besonders relevant für Snyks Behauptung. Eine Organisation muss Modell, beabsichtigte Aufgabe, Nutzer, Daten, Abhängigkeiten, Bereitstellungskontext und betroffene Parteien identifizieren, bevor sie Risiken messen kann. Ein Scanner kann nicht jede fehlende Richtlinie oder Eigentümerentscheidung wiederherstellen.
Auch Messung benötigt Tests. Ein Unternehmen kann die vorgesehenen Berechtigungen eines Agenten dokumentieren, seine tatsächlich wirksamen Berechtigungen in der Produktion jedoch nie überprüfen. Es kann genehmigte Tools erfassen und gleichzeitig Funktionen übersehen, die durch eine aktualisierte Integration hinzugefügt wurden.
Die skeptische Position lautet daher nicht, dass der blinde Fleck eingebildet ist. Vielmehr kann die Telemetrie eines einzelnen Anbieters seine exakte Größe im gesamten Markt noch nicht definieren. Die Schlagzeile sollte zu Inventarisierung und Tests motivieren, nicht als Ersatz für beides dienen.
Sicherheitsverantwortliche sollten Anbieter fragen, wie sie die Abdeckung berechnen. Sie sollten den Nenner, Erkennungsmethoden, ausgeschlossene Umgebungen, Aktualisierungsfrequenz und den Prozess zur Auflösung doppelter oder veralteter Assets anfordern. Ein präziser Prozentsatz ohne diesen Kontext kann falsches Vertrauen erzeugen.
Sie sollten außerdem Ergebnisse messen. Mehr Komponenten zu finden ist nur dann nützlich, wenn die Organisation gefährliche Beziehungen priorisieren, Verantwortliche zuweisen, Berechtigungen reduzieren und bestätigte Pfade beheben kann. Ein größeres Inventar, das eine unbeherrschbare Warnwarteschlange erzeugt, kann zu einer weiteren Form der Blindheit werden.
Drei Signale werden zeigen, ob sich der blinde Fleck schließt
Die nächste Phase wird anhand von Identitätszuordnung, Komponenteninventaren und nachweislich verringerten gefährlichen Agentenberechtigungen gemessen werden.
Das erste Signal ist, ob Unternehmen Agentenaktivität in ihren Protokollen von menschlicher Aktivität trennen können. Die Feststellung der Cloud Security Alliance von 68 % liefert eine klare Ausgangsbasis, auch wenn sie auf einer Umfrage und nicht auf direkter Telemetrie beruht.
Eine Verbesserung würde bedeuten, dass jede folgenschwere Aktion eine Agentenidentität, eine Nutzerdelegation, einen Tool-Namen, einen Autorisierungskontext und ein nachvollziehbares Ergebnis trägt. Wenn spätere Umfragen zeigen, dass weniger Organisationen mit der Zuordnung kämpfen, wird die Grundlage für eine beherrschbare Agenten-Governance stärker.
Bleibt die Zahl bei etwa zwei Dritteln, folgt die gegenteilige Schlussfolgerung. Unternehmen werden mehr autonome Workflows eingeführt haben, ohne grundlegende Rechenschaftspflicht zu lösen. Dieses Ergebnis würde Snyks Warnung stärken, dass die Sichtbarkeitslücke mit der Einführung wächst.
Das zweite Signal ist das Entstehen konsistenter KI-Stücklisten. Eine KI-Stückliste erfasst Modelle, Datensätze, Prompts, Frameworks, Tools, Dienste und Abhängigkeiten, die ein System verwendet. Sie erweitert das Konzept der Software-Stückliste auf KI-spezifische Komponenten.
Die nützliche Version muss mit der Bereitstellung synchron bleiben. Ein statisches Dokument, das während der Beschaffung erstellt wird, verfehlt die später angebundenen Tools und Datensätze. Automatisierte Erkennung, Zuweisung von Verantwortlichen, Versionshistorie und Nachweise über tatsächlich wirksame Berechtigungen sind wichtiger, als lediglich eine Liste zu erstellen.
Eine breite Einführung interoperabler Inventarformate würde das Argument stärken, dass Unternehmen die Sichtbarkeit zurückgewinnen können. Eine anhaltende Abhängigkeit von anbieterspezifischen Dashboards würde blinde Flecken zwischen Sicherheitsprodukten, Cloud-Plattformen und lokalen Umgebungen bestehen lassen.
Das dritte Signal ist, ob Organisationen übermäßige Handlungsfreiheit in der Produktion verringern. Sicherheitsteams sollten verfolgen, wie viele Agenten Daten schreiben, Code ausführen, Kommunikation versenden, Infrastruktur verändern oder auf sensible Repositories zugreifen können, ohne dass eine separate Freigabe erforderlich ist.
Eine sinkende Zahl würde zeigen, dass Unternehmen KI-Governance in technische Kontrollen übersetzen. Eine steigende Zahl würde darauf hindeuten, dass Produktivitätsziele weiterhin Vorrang vor Eindämmung haben. Vorfallberichte über überprivilegierte Agenten würden diese Kennzahl besonders dringlich machen.
Diese Signale sind wichtiger als die Menge der von Unternehmen veröffentlichten KI-Richtlinien. Richtlinien beschreiben Absichten. Identitäten, Inventare, Berechtigungen und Protokolle offenbaren die betriebliche Realität.
Snyks Google-News-Schlagzeile funktioniert, weil sie diese Realität in einer einprägsamen Warnung verdichtet. Die exakte Zwei-Drittel-Zahl bleibt eine anbieterseitig abgeleitete Schätzung, doch die zugrunde liegende Diskrepanz ist schwer abzutun. KI-Komponenten vermehren sich schneller, als viele Organisationen sie entdecken, klassifizieren und steuern können.
Für Entwickler lautet die unmittelbare Frage, ob jede Agentenverbindung einen benannten Verantwortlichen und eine notwendige Berechtigung hat. Für Sicherheitsteams lautet sie, ob Protokolle eine Aktion von der Nutzeranfrage über die Modellentscheidung bis zum nachgelagerten Ergebnis rekonstruieren können. Unternehmenskäufer sollten für beides Nachweise verlangen.
Das nächste Quartal bietet einen praktischen Test. Wählen Sie einen Produktionsagenten aus, erfassen Sie jedes Modell, Tool, jede Identität, jeden Datensatz und jeden externen Aufruf und vergleichen Sie diese Karte dann mit den vorhandenen Sicherheitsaufzeichnungen. Weichen die beiden Ansichten stark voneinander ab, befindet sich der blinde Fleck bereits innerhalb der Organisation. Stimmen sie überein, testen Sie, ob Berechtigungen und Freigabekontrollen wie dokumentiert funktionieren. Google News lieferte die Warnung; die Unternehmenstelemetrie muss nun die Antwort liefern.
