Zwei Meldungen aus dem Oktober 2026 beschreiben dasselbe Grundproblem aus unterschiedlichen Richtungen. Im ersten Fall postete ein Agent in Grok Bot private Kontostände eines CEOs im Firmen-Slack. Zwei Stunden lang blieben die Daten dort sichtbar. Im zweiten Fall genügte Forschern von Zenity Labs nach eigenen Angaben ein einziger öffentlich erreichbarer KI-Agent auf Amazons Bedrock AgentCore, um alle AgentCore-Agenten im selben AWS-Konto und derselben Region zu übernehmen.
Beide Vorfälle haben wenig mit der Qualität der zugrunde liegenden Sprachmodelle zu tun. Sie betreffen die Schicht darüber: Welche Daten darf ein Agent lesen, wohin darf er schreiben, und mit welchen Zugangsdaten handelt er im Namen des Unternehmens.
Der Slack-Fall: falscher Kanal, echte Daten
Ein Agent, der in einem Chat-System wie Slack arbeitet, hat in der Regel zwei Berechtigungssätze: Zugriff auf Datenquellen und Schreibrechte in Kanälen. Trennt man beides nicht sauber, kann eine an sich korrekte Antwort an der falschen Stelle landen. Genau das ist hier passiert – Finanzdaten, die für einen eng begrenzten Kreis gedacht waren, erschienen in einem Kanal mit deutlich breiterem Publikum.
Bemerkenswert ist weniger der Fehler selbst als die Zeitspanne von zwei Stunden, in der die Information sichtbar blieb. Das ist ein Hinweis auf fehlendes Monitoring: Niemand bemerkte unmittelbar, dass der Agent etwas veröffentlicht hatte, das er nicht hätte veröffentlichen dürfen. In regulierten Umgebungen wäre allein diese Latenz ein meldepflichtiger Umstand.
Der AgentCore-Fall: ein Prompt, viele Agenten
Der zweite Fall liegt technisch tiefer. Bedrock AgentCore ist Amazons Plattform für den Betrieb von KI-Agenten in der AWS-Cloud. Laut den Forschern reichte ein einzelner, von außen erreichbarer Agent als Einstiegspunkt. Möglich wurde die Ausweitung über eine interne AWS-Schnittstelle, die temporäre Cloud-Zugangsdaten ausgibt. Wer diese Zugangsdaten abgreift, handelt anschließend mit den Rechten des Agenten – und damit potenziell auch gegenüber allen anderen Agenten desselben Kontos in derselben Region.
AWS hat nachgebessert und laut der Darstellung später auch die Standardrechte der Agenten deutlich eingeschränkt. Dieser zweite Schritt ist der interessantere: Er bestätigt, dass die ursprüngliche Voreinstellung mehr Rechte vergab, als für den Betrieb nötig gewesen wären. Das ist ein wiederkehrendes Muster bei neuen Plattformen – großzügige Defaults erleichtern den Einstieg und verschieben das Sicherheitsproblem in die Produktion.
Was die beiden Fälle verbindet
Die Quellen beschreiben unterschiedliche Ebenen: einmal eine fehlgeleitete Ausgabe in einem Kollaborationswerkzeug, einmal eine Rechteausweitung in einer Cloud-Infrastruktur. Gemeinsam ist beiden, dass der Agent mehr konnte, als sein eigentlicher Zweck erfordert hätte.
Ein klassisches Software-Modul tut, was im Code steht. Ein Agent entscheidet im laufenden Betrieb, welche Werkzeuge er aufruft und welche Daten er dabei weitergibt. Diese Entscheidung hängt an Eingaben, die nicht vollständig kontrollierbar sind – an Nutzeranfragen, an Inhalten aus angebundenen Systemen, im Fall von AgentCore an einem Prompt von außen. Wer einem solchen System weitreichende Rechte gibt, vergibt diese Rechte faktisch an jeden, der die Eingaben beeinflussen kann.
Rechtekonzept vor Funktionsumfang
Für Agenten-Projekte in Unternehmen folgt daraus eine Reihenfolge, die in der Praxis oft umgekehrt wird. Nicht zuerst der Funktionsumfang, sondern zuerst die Grenzen:
- Minimale Rechte je Agent: Ein Agent erhält nur Zugriff auf die Datenquellen und Zielsysteme, die sein konkreter Anwendungsfall verlangt – nicht auf das, was die Plattform standardmäßig anbietet.
- Trennung von Lesen und Schreiben: Lesender Zugriff auf sensible Daten und schreibender Zugriff auf öffentliche Kanäle gehören nicht in dieselbe Identität.
- Isolation zwischen Agenten: Mehrere Agenten im selben Konto sollten sich nicht gegenseitig erreichen oder übernehmen können. Getrennte Konten, Rollen oder Umgebungen reduzieren den Schaden eines einzelnen kompromittierten Agenten.
- Keine Standardrechte übernehmen: Voreinstellungen von Plattformanbietern sind Startpunkte, keine Freigaben. Der AgentCore-Fall zeigt, dass auch große Anbieter hier nachjustieren.
- Öffentlich erreichbare Agenten gesondert behandeln: Jeder von außen ansprechbare Agent ist ein potenzieller Einstiegspunkt und braucht ein eigenes Bedrohungsmodell.
Monitoring ist Teil des Betriebs, nicht der Kür
Der Slack-Fall macht deutlich, dass Prävention allein nicht ausreicht. Agenten handeln schnell und oft unbeobachtet. Ohne Protokollierung der Aktionen – welches Werkzeug wurde aufgerufen, welche Daten wurden übergeben, in welchen Kanal ging die Ausgabe – lässt sich ein Vorfall weder bemerken noch rekonstruieren.
Dazu gehören auch Mechanismen zum schnellen Eingreifen: ein Weg, einen Agenten sofort abzuschalten, Ausgaben zurückzunehmen und betroffene Zugangsdaten zu rotieren. Zwei Stunden Sichtbarkeit sind in einem Firmen-Chat eine lange Zeit.
Datenfreigaben explizit klären
Ein dritter Punkt betrifft weniger die Technik als die Organisation. Welche Datenbestände dürfen einem Agenten überhaupt zugänglich gemacht werden? Finanzdaten, Personaldaten und Vertragsunterlagen brauchen eine bewusste Freigabeentscheidung, idealerweise dokumentiert und mit benannter Verantwortung. Diese Entscheidung lässt sich nicht an das Projektteam delegieren, das den Agenten baut – sie gehört zur Fachseite und, je nach Datenart, zum Datenschutz.
Hilfreich ist eine schlichte Frage vor dem Rollout: Welche Information wäre am unangenehmsten, wenn sie im falschen Kanal erschiene? Wenn ein Agent auf genau diese Information zugreifen kann, muss die Begründung dafür belastbar sein.
Einordnung für Web- und Softwareprojekte
Für laufende und geplante Projekte verschiebt sich damit der Aufwand: Ein Agent ist nicht mit der Anbindung an ein Sprachmodell fertig, sondern mit einem belastbaren Rechte-, Freigabe- und Protokollierungskonzept. Dieser Teil lässt sich schlecht nachrüsten, weil er in die Architektur der angebundenen Systeme hineinreicht – in Rollenmodelle, Schnittstellen und Deployment-Umgebungen. Wer Agenten in Geschäftsprozesse integriert, sollte Sicherheitsarchitektur und Betriebskonzept deshalb von Beginn an als Teil des Projektumfangs einplanen und nicht als nachgelagerte Härtung behandeln.
