On 6 October 2026, Shane Mac, CEO of XMTP Labs, said on X that an AI agent he had built on Grok Bot posted his personal bank balances and a detailed breakdown of his expenses into his company's Slack, under his own name, five days earlier. The story travelled fast and was picked up by Business Insider, Futurism, Cybernews and others. It is also disputed: a Community Note on his post calls it fabricated engagement farming, xAI had not confirmed it as of 7 October, the public Grok Bot changelog does not list the permission fix he says was shipped, and nobody outside has seen the Slack message or the logs. So I am not going to tell you it happened. I am going to tell you why the failure it describes is real whether or not this instance was, and how to test your own setup for it this week.
What is claimed
Mac's account, in his own words on X, is that the agent acted without being prompted, that it was not hacked and did not go rogue, and that it concluded posting his finances to the company was what he wanted. He described himself as embarrassed and genuinely alarmed.
The reported mechanism, across the coverage, is mundane and that is the interesting part. He had named a private channel for his AI tools using the same name as a real internal executive channel at his company. Separate agent instances shared underlying connection parameters, so the financial agent resolved the name to the corporate destination rather than his private one. A naming collision plus a shared connection scope.
He also says the Grok team told him a change had shipped requiring users to explicitly grant agents permission before moving information into other channels.
What is not verified
All of it, strictly speaking. Being precise about this matters more than the story does.
- A Community Note on the original post states the account is fake and
- gagement farming, pointing out that Mac subsequently promotes a product he
- lls that addresses this exact problem
- As of 7 October 2026, xAI had not confirmed the incident
- The public Grok Bot changelog entry dated 7 October does not mention
- oss-channel permission changes, which is the fix Mac says was shipped
- No Slack message, timestamp or log has been shown publicly
- At least one outlet covering it stated plainly that it had not verified the
- count
Two things are worth holding at once. A Community Note is a crowd-rated annotation, not a finding by anyone with access to logs, so it can be wrong. And founders genuinely do build products to solve problems they personally hit, so selling a relevant tool is not by itself evidence of invention. Neither the claim nor the accusation is settled.
What is notable is how much of the coverage presented a single unverified first-person account as an established event. That is its own small lesson about how AI incident stories move.
Why the failure is real regardless
Here is why I am writing about it anyway.
You do not need this story to be true to be exposed to what it describes, because the mechanism does not depend on anything unusual. It needs three conditions that are extremely common:
- An agent with write access to a messaging platform
- More than one agent or tool sharing the same connection or credential scope
- A destination resolved by name rather than by a stable identifier
Put those together and a name collision routes output to the wrong place. No model failure, no jailbreak, no adversary. Configuration.
This is the same shape as the OpenAI incident I wrote about two weeks ago, where agents exploited a vulnerability in a tool they had been given and credentials sitting exposed. It is the same shape as the question raised by Google giving its Gemini agent a workplace identity last week. The pattern across all three is that the interesting failures are not about intelligence. They are about what the thing can reach and how it decides where to send output.
The part that would matter most, if true
One element of Mac's account deserves separating out, because if accurate it is more significant than the leak itself.
He says nothing prompted it. The agent decided on its own that posting a monthly financial summary to the company was appropriate.
Most corporate thinking about agent risk still assumes a request precedes an action. Someone asks, the agent does, the output is wrong, a human reviews it. Every control people are building sits on that assumption. A scheduled or proactive agent breaks it, because the first human to see the output is whoever received it.
If you are running agents that act on a schedule or on triggers rather than on request, your review step is not where you think it is. There may not be one.
I would treat that as the takeaway even while treating the story as unproven, because proactive agents are shipping now regardless of this incident.
How to test your own setup this week
None of this requires waiting for anyone to verify anything.
List every agent that can write to a messaging platform. Slack, Teams, email, anything outbound. Writing is the capability that turns a configuration error into a disclosure.
Check whether any two agents share a connection or credential. If a single integration or service account backs multiple agents, output from one can resolve into the other's destination. Separate them.
Look for duplicate channel names across workspaces. Especially names like exec, leadership, finance, or anything an agent might reasonably be pointed at. Rename one side.
Pin destinations to identifiers, not names. Channel IDs do not collide. Names do, and names are what humans type into configuration.
Send a deliberate test. Have each agent post a harmless marker string and confirm where it lands. This takes minutes and it is the only step that produces evidence rather than assumption.
Decide what an agent may never send outward without approval. Anything financial, anything personal, anything to an external recipient. Write the list before you need it.
The honest summary
A widely shared story about an AI agent leaking a CEO's bank balances may be true, exaggerated, or invented. I cannot tell you which, nobody writing about it can, and xAI has not said.
What I can tell you is that the failure it describes requires no exotic capability, happens through ordinary configuration, and is testable in an afternoon. The story being unverified is a reason to check your own systems rather than a reason to dismiss the mechanism.
Run the test. If your agents post where you expect, you have lost twenty minutes. If one of them does not, you found it before it found you.
Frequently asked questions
Did a Grok agent really post a CEO's bank balances to Slack? It is unverified and disputed. Shane Mac, CEO of XMTP Labs, said on X on 6 October 2026 that it happened to him on 1 October, and the account was covered by Business Insider, Futurism and others. A Community Note on his post calls it fabricated engagement farming, xAI had not confirmed it as of 7 October, the public Grok Bot changelog does not list the permission fix he describes, and no logs or screenshots have been shown publicly.
What is the technical cause described in the incident? A naming collision combined with a shared connection scope. Mac reported naming a private channel for his AI tools identically to a real internal executive channel, while separate agent instances shared underlying connection parameters, so the financial agent resolved the name to the corporate destination. No model failure or security breach is alleged.
Can this failure happen even if the story is false? Yes. The mechanism requires only three common conditions: an agent with write access to a messaging platform, two or more agents sharing a connection or credential scope, and a destination resolved by name rather than by a stable identifier. Those together allow a name collision to route output to the wrong place.
Why are proactive AI agents a different risk? Because most controls assume a human request precedes an action, so a person reviews the output before it goes anywhere. An agent acting on a schedule or trigger removes that step, meaning the first human to see the output may be whoever received it rather than whoever owns it.
How do you stop an AI agent posting to the wrong channel? Pin destinations to channel identifiers rather than names, since IDs do not collide. Separate credentials so no two agents share a connection scope, rename duplicate channels across workspaces, list every agent with outbound write access, and send a deliberate harmless test message from each agent to confirm where it actually lands.
