Eine bei The Hacker News veröffentlichte Analyse vertritt die These, dass die meisten Sicherheitsmaßnahmen für Unternehmens-KI das falsche Ziel haben. Der Beitrag, von einem Partner beigesteuert und mit Werbematerial versehen, argumentiert, dass Kontrollen, die für eine bewusst eingeführte KI entwickelt wurden, die Agenten übersehen, die innerhalb bereits genutzter Software ankommen. Es handelt sich um einen Meinungsbeitrag. Er beschreibt weder einen Einbruch, eine Schwachstelle noch eine behördliche Maßnahme.
Drei Wege, auf denen ein Agent ins Unternehmen gelangt
Der Autor ordnet Agenten danach, wie sie ankommen:
- Inherited: mit einem routinemäßigen Produkt-Update in eine bestehende Plattform eingebaut.
- Configured: aus den eigenen Prompts und der eigenen Logik des Unternehmens gebaut, läuft aber auf der Laufzeitumgebung, dem Modell und den Konnektoren eines Anbieters.
- Built: aus offenen Frameworks auf einer Infrastruktur zusammengesetzt, die dem Unternehmen gehört.
Nach Darstellung des Autors machen die ersten beiden Gruppen die „überwältigende Mehrheit“ der Einführungen aus und wachsen „exponentiell“. Selbst gebaute Agenten gelten als die kleinste und am langsamsten wachsende Gruppe. Der Beitrag liefert keine Messung, die diese Einordnungen stützt.
Die Folge, so der Autor, ist, dass sich niemand bewusst für einen Inherited-Agenten entscheidet. Er taucht mit einem Update auf, daher findet die Prüfung, die einer neuen KI-Einführung normalerweise vorausgeht, nie statt.
Eine Zahl aus einem nicht genannten Bericht
Der Artikel zitiert den „2026 State of Agent Security Report“, ohne einen Herausgeber zu nennen oder Methode und Stichprobe zu beschreiben. Laut diesem Bericht betten rund 1.280 Drittanbieterprodukte in den untersuchten Umgebungen KI ein. Etwa 282 davon hängen an Single Sign-on.
Der Autor deutet die Lücke so, dass die „übrigen tausend“ standardmäßig für die Identitätsinfrastruktur unsichtbar bleiben. Dabei handelt es sich um Anzahlen von Produkten, nicht von Agenten oder Personen. Die übrigen Größenbeispiele des Artikels, etwa fünfzig, fünfhundert und fünftausend Agenten, sind Veranschaulichungen und keine Daten.
Das Beispiel Slack Code
Die zentrale Fallstudie des Autors ist Slack Code, das laut Artikel Salesforce im August 2026 eingeführt hat. Ein Nutzer markiert den Coding-Agenten in einer Unterhaltung. Dieser liest den geteilten Kontext, schreibt Code und eröffnet Pull Requests, mit Zugriff auf GitHub und die Produktivinfrastruktur, wie der Artikel schreibt.
Die Ankündigung von Salesforce, im Beitrag zitiert, sagt, Agenten übernehmen „vom ersten Tag an das integrierte Sicherheitsmodell, die Berechtigungen und die Admin-Kontrollen von Slack, ohne zusätzlichen IT-Aufwand“. Der Artikel stellt dieses Versprechen der weitreichenden Reichweite des Agenten über Slack hinaus gegenüber.
Wo der Autor das Risiko verortet
Der Beitrag hält fest, dass das Risiko vor allem in der Umgebung des Agenten liegt, also in seinem Gerüst und dem umgebenden Ökosystem, und nicht im zugrunde liegenden Modell. Er schlägt vier Prüfbereiche vor:
- Identität: Welcher Agent handelt, und in wessen Auftrag.
- Berechtigungen: Wozu er befugt ist.
- Konnektivität: Der Wirkungsradius, einschließlich dessen, was er indirekt über andere Systeme erreichen kann.
- Aktivität: Eine Bewertung auf Grundlage des beobachteten Verhaltens, nicht der erklärten Absicht.
Opet und der EU AI Act
Der Autor beruft sich auf Patrick Opet, globaler CISO von JPMorgan Chase. Opet habe 2025 die Lieferkette von Drittanbietern als systemisches Risiko beschrieben, so der Artikel. Die Vorfälle seien so gravierend gewesen, dass die Bank kompromittierte Zulieferer isoliert habe; dies sei in einem offenen Brief dargelegt worden. Details zu diesen Vorfällen nennt der Artikel nicht.
Der Autor schreibt Opet außerdem die Position zu, ein Agent solle standardmäßig eine Identität, aber keine Berechtigungen erhalten. Bevor er etwas außerhalb seines Bereichs berührt, solle die IT bestätigen, für wen er handelt.
Zur Regulierung sagt der Autor, der EU AI Act, dessen Pflichten schrittweise bis 2026 greifen, setze voraus, dass Unternehmen ihre KI-Systeme inventarisieren, Verantwortliche benennen und Aufsicht nachweisen können. Das sei schwierig, so der Beitrag, wenn Agenten unangekündigt in Produkten von Anbietern auftauchen.
Die Anbieterperspektive
Der Artikel nennt Reco und dessen Plattform Reco Graph als „führendes Beispiel“ für ein Werkzeug, das menschliche und nicht-menschliche Identitäten, Anwendungen, Berechtigungen und Agentenaktionen in einer Live-Ansicht verknüpft. Der Beitrag stammt von einem Partner, daher ist diese Empfehlung das Eintreten des Beitragenden für das Produkt. Die Agentenerkennung von Reco wird unter reco.ai/platform erwähnt.
Für Sicherheitsteams ist die praktische Schlussfolgerung enger als der Verkaufsvortrag. Das Argument lautet, dass ein Inventar der Agenten bei den bereits genutzten SaaS-Anwendungen beginnen sollte und nicht bei einer Liste genehmigter KI-Projekte.
