Grok Bot: KI-Agent postet Kontostände im Firmen-Slack

Ein einzelner Agent in Grok Bot soll am 1. Oktober 2026 die privaten Kontostände und Ausgaben von Shane Mac im Firmen-Slack von XMTP Labs gepostet haben — unter Macs eigenem Namen und rund zwei Stunden lang sichtbar. Bekannt wurde der Fall durch einen X-Thread des betroffenen CEO vom 6. Oktober; die öffentliche Meldung dazu datiert auf den 9. Oktober. Unabhängig belegt ist bislang nichts davon: Slack-Nachricht und Logs sind nicht öffentlich, eine Stellungnahme des Anbieters liegt nicht vor.

Damit ist der Vorfall kein nachgewiesener Angriff im Feld und auch kein bestätigter Produktfehler, sondern eine Behauptung mit plausibler Mechanik. Für Unternehmen, die KI-Agenten auf Finanzdaten, Firmen-Accounts oder Chat-Integrationen ansetzen, ist vor allem diese Mechanik relevant.

Grok Bot: der gemeldete Ablauf

Der Agent trug den Namen „personal CFO" und hatte einen einzigen Auftrag: einen monatlichen Finanz-Audit erstellen und privat an Mac senden. Am 1. Oktober um 8:40 Uhr erschien dieser Audit laut der dokumentierten Chronologie stattdessen im Team- beziehungsweise Exec-Channel. Rund zwei Stunden blieb er dort stehen, bis ein Teammitglied Mac per Direktnachricht warnte.

Der Inhalt ging über nackte Beträge hinaus: Neben Kreditkarten-Abbuchungen sollen Fitnessstudio-Beiträge, Reparaturen am Haus, Arbeiten an Septik-Tank und Drainage sowie ein als „barn-based home gym project" bezeichnetes Vorhaben sichtbar gewesen sein. Wie in der Auswertung des Falls beschrieben, war die angebundene Bankverbindung nur lesend eingebunden. Der Finanz-Agent selbst besaß gar keinen Slack-Zugang — ein anderer Bot im selben Konto hatte ihn. „They’re all connected", so Macs Zusammenfassung.

Mac erklärte, der Agent sei nicht gehackt worden und nicht „rogue" unterwegs gewesen; niemand habe ihn zu dem Post aufgefordert, er habe das Veröffentlichen für gewollt gehalten. Anschließend habe er „all my personal stuff" getrennt und angekündigt, Permissions besser zu verwalten.

Geteilte Cloud-Computer als eigentliche Fehlerquelle

Laut der zitierten Produktdokumentation ist der Cloud-Computer bei Grok Bot pro Nutzer zugewiesen, nicht pro Bot; einzelne Bots sollen ausdrücklich nicht als Sicherheitsgrenze dienen. Wer zwei Agenten unter demselben Konto betreibt, erhält damit keine Trennung, sondern zwei Oberflächen auf derselben Umgebung mit denselben Connectoren.

Genau hier liegt ein Widerspruch in der öffentlichen Darstellung. Die Produktankündigung sprach laut Sekundärberichten davon, dass jeder Bot einen eigenen Cloud-Rechner erhalte. Die dokumentierte Zuweisung pro Nutzer und der geschilderte Fall passen dazu nicht zusammen. Eine Einordnung des Disputs hält zudem fest, dass es keine öffentliche Dokumentation dazu gibt, ob Connectoren unter einem Nutzer über mehrere Bots hinweg geteilt werden.

Für die Bewertung ist ein Punkt wichtig: Ein Sprachmodell trifft keine Entscheidung darüber, wohin es schreibt. Es gibt Token-Wahrscheinlichkeiten aus, die Route bestimmt der Kontext — Channel-ID, Session, Berechtigungen. Formulierungen wie „der Agent glaubte" beschreiben eine Ausgabe, keine Absicht. Kontrollierbar ist deshalb nicht die Absicht, sondern der Zugriff: Wer darf in welchen Channel schreiben, mit welchem Identitätskontext, und was teilt sich diese Identität mit anderen Agenten?

Unbestätigt, umstritten, Interessenkonflikt möglich

Der Fall ist öffentlich umkämpft. Eine Community Note zu dem Post bezeichnet ihn als „fake" und als Engagement-Farming; der Autor verweise später auf ein eigenes Tool, das genau dieses Problem löse. Diese Note ist selbst Teil der Behauptungslage, zeigt aber, warum Primärevidenz fehlt: Slack-Nachricht, Zeitstempel und Agenten-Konfiguration sind nicht öffentlich, der Anbieter hat den Vorfall nicht bestätigt.

Ein möglicher Interessenkonflikt kommt hinzu: Mac arbeitet laut der Darstellung mit Zitaten aus seinem Tweet selbst an einem Agenten-Tool, das Nutzern mehr Kontrolle über verbundene Bots geben soll. Das macht den Bericht nicht falsch, aber es ist ein Motiv, das bei der Bewertung mitzählt. Auch die Reichweitenzahlen des Threads weichen zwischen den Quellen deutlich voneinander ab — von rund 670.000 über knapp 692.000 bis etwa 800.000 Views.

Produktseitig fällt der Fall in eine laufende Vermarktung: Grok Bot wurde am 11. August 2026 als Set „always-on" arbeitender Agenten gestartet und zunächst intern für Vertrieb, Marketing, Office-Ops und Bugfixes genutzt. Laut einer Chronologie postete Elon Musk 34 Minuten nach Macs Thread, „Grok @Bot can be your personal chief financial officer!" — ein Post mit über 26 Millionen Views. Ein früherer Post vom 27. August soll zugesagt haben, Nutzer „whole" zu machen, falls Grok Bot etwas vermasselt. Solche Aussagen sind Marketing, keine Haftungszusage — und sie ersetzen keine technische Trennung.

Was Admins jetzt prüfen sollten

Unabhängig davon, ob der Vorfall sich so zugetragen hat, lassen sich daraus konkrete Prüfschritte ableiten:

Konto- statt Bot-Grenzen: Wenn ein Anbieter die Ausführungsumgebung pro Nutzer statt pro Agent zuweist, ist die Trennung über separate Bot-Namen wirkungslos. Für sensible Aufgaben eigene Konten oder Workspaces verwenden, nicht mehrere Bots unter einer Identität.
Berechtigungen pro Identität prüfen: Eine read-only angebundene Datenquelle schützt nichts, wenn dieselbe Identität über einen anderen Agenten Schreibzugriff auf einen Chat-Channel hat. Rechte gehören an die Identität, nicht an den einzelnen Connector.
Ziel-Channels explizit begrenzen: Agenten sollten ausschließlich in dafür vorgesehene Channels schreiben dürfen, nie in Team- oder Exec-Channels, in denen Standardmitglieder mitlesen.
Vor Produktivbetrieb testen: Mit harmlosen Testdaten prüfen, wo die Ausgabe tatsächlich landet — und mitprotokollieren, welche Aktionen der Agent ausführt und unter welchem Namen.
Herstelleraussagen einordnen: Zusagen zur Isolation und zu „persönlichen" Agenten sind Ankündigungstexte. Vertraglich relevant sind SLA, Haftung und dokumentierte Isolationsgrenzen — Letztere fehlen im vorliegenden Fall teilweise.

Der eigentliche Lernwert liegt nicht in einem einzelnen Datenleck, sondern in der Architekturfrage: Solange Agenten innerhalb eines Kontos gemeinsame Connectoren und Identitäten nutzen, ist jeder zusätzliche Bot ein zusätzlicher Schreibpfad auf dieselben Daten. Wer Agenten mit Finanz- oder Personaldaten betraut, sollte diese Pfade prüfen, bevor der erste Bot produktiv läuft — und nicht erst nach zwei Stunden Sichtbarkeit.

Quellen