Grok Bot's Bank Leak Shows Separate AI Agents Are Not Separate Permissions

Named agents with different jobs feel isolated. On many platforms they share one browser, one credential store and one blast radius.

A read-only agent cannot post anything, so it cannot leak anything. That sentence sounds obviously true, and this week it turned out to be false in a way that ended up in a company Slack channel.

Shane Mac, the CEO of XMTP Labs, connected Grok Bot to his personal bank account so it could watch his finances as a read-only "CFO." According to Cybernews's October 7 report, a different Bot on his account, one that did have Slack access, then posted a "monthly financial audit" of his balances and spending to a company channel while posing as him. A teammate flagged it. Business Insider carried the story on October 10.

The finance Bot never touched Slack. It did not need to.

The part that was in the docs all along

Mac's explanation, as Cybernews reports it, is that his agents were "all connected" and share one cloud computer. That is his account, and nobody at SpaceXAI has publicly confirmed or disputed the specific chain of events. What you can confirm is the design, because the Grok Bot documentation states it plainly.

The FAQ says: "The computer is assigned per user, not per Bot. Do not use separate Bots as a security boundary."

The computer and apps page lists what that sharing covers. Browser cookies and signed-in sessions are shared. Command-line credentials are shared. Files are visible to every Bot. "Installed connectors are account-wide." Each Bot gets its own screen, and the docs add, "The screens are separate work surfaces, not separate security boundaries." Then the instruction that matters most: "Do not place a credential or file on it if another Bot on your account should not be able to use it."

So the product told users, in writing, that the thing Mac relied on does not exist. Each Bot has its own name, its own job, its own conversations and its own learned context ("Conversations and learned context stay separate per Bot," per the overview). Memory is per Bot. The computer is not.

That split is the trap. The parts you see every day (the name, the chat history, the role) are separate. The parts that decide what an agent can touch (cookies, tokens, files) are pooled.

Why "read-only" stopped meaning anything

Think of permissions the way an attacker does. An attacker never asks what one agent is allowed to do. They ask what the most permissive agent on the same machine can reach, and then they ask how to get a request in front of it.

On a shared computer, the answer to the first question is "everything any Bot has ever signed into." The answer to the second is "any content any Bot reads." Grok Bot's security page is honest about that second part: outside content is marked as untrusted before it reaches the model, and "These controls reduce, but do not eliminate, risk from malicious content."

Put those together. A finance Bot that reads bank data writes or caches something on the shared computer. A Slack Bot reads a message, a doc or a web page, misreads its task or gets steered, and goes looking for material on the same disk. Whether Mac's leak happened exactly that way, I cannot verify. The point is that the design allows it, and the docs say so.

The security page has more that belongs in every buyer's notes:

Teams without a network policy default to allow-all, and network controls are Enterprise only.
"Dedicated data loss prevention hooks are not available."
"Deleting a Bot does not remove computer files or browser sessions."

That last line deserves a second read. Retiring the finance Bot would not have retired the bank session it signed into.

There is a real counterargument here. A shared computer is convenient. One login serves every Bot, files persist across jobs, and you do not juggle five browser profiles. For most work (research, drafting, scheduling) pooling is a fair trade. My position is narrower: pooling is fine until one agent holds something another agent should never see, and then the agent's name stops mattering and only the machine boundary counts.

This is not only a Grok Bot problem

Grok Bot is the clearest case this week because its docs spell it out. The same question applies to every agent product that lets you create several named assistants.

Look at how other tools word it. VS Code 1.141, released October 7, added sandboxing for agent terminals and locally launched MCP servers, and its release notes say the sandbox "does not replace endpoint security or provide a standalone security boundary." The same release lets an agent use a send_message tool to steer, queue or cancel messages in another session on the same agent host. Two sessions on one host can now talk to each other, which is useful and also one more path from a compromised session to a trusted one.

GitHub went the other direction on identity this week. Its October 9 Copilot roundup says the Copilot app can now use one GitHub account for the Copilot license and a separate one for repository access. That is the right instinct: when you want two trust levels, you need two identities, not two names.

The rule underneath all three: an agent's real permission set is the union of everything reachable from the environment it runs in. The persona is a label on top.

Put this into practice

You do not need to drop multi-agent tools. You need a map and two or three splits.

1. Map agents by what they share, not what they are called. List every agent you run. Next to each, write the machine or container it runs in, the browser profile it uses, the credential files and environment variables it can read, and the connectors installed at the account level. Any two agents sharing any of those columns belong to the same trust zone, whatever their names.

2. Give sensitive data its own account or machine. If a finance, HR or customer-data agent must exist, run it under a separate account (on Grok Bot, that means a separate user, since isolation "between users" is where the docs draw the hard line) or on a separate machine with no chat or email connectors. Make the split physical.

3. Never place long-lived credentials on a shared agent computer. The Grok Bot docs say it in one sentence, so follow it: if another Bot should not use a credential, it should not be on that computer. Prefer connectors that hold tokens server-side (Grok Bot's security page says "Connector tokens are never stored on the computer") over logging in through the shared browser.

4. Add "ask first" rules for anything that publishes. Grok Bot's FAQ recommends narrow "Ask first" rules for sending, publishing, deleting, purchasing or changing production systems, and the security page says those rules "always stop matching actions." Posting to a company Slack channel is publishing. Put it behind a human.

5. Clean up when you retire an agent. Deleting the Bot leaves its files and sessions behind. Sign out of the sites it used, revoke its tokens and clear its folders by hand.

6. Test the boundary you think you have. Ask your least privileged agent to list the files and signed-in sessions it can see. If the answer includes another agent's work, you have your map.

Honest limitations of this argument

The leak details come from Mac's own account as reported by Cybernews. Business Insider's article was not readable from my research environment, and SpaceXAI has not commented in any coverage I found. It is possible the chain was different, for instance a single misconfigured Bot, and the shared computer was incidental.

The Grok Bot docs I quote are current as of October 10 and could change. The security page does not say how Bots belonging to the same user are isolated from each other, which is consistent with the FAQ's "do not use separate Bots as a security boundary" but is an absence, not a statement.

Splitting accounts has costs. You pay for more seats or juggle more logins, you lose shared files between agents, and on team plans an admin-set policy may limit what you can separate. Some tools also offer no per-agent credential scoping at all, which leaves a separate machine as the only clean option.

And none of this fixes prompt injection. Separation limits what a fooled agent can reach. It does not stop the agent from being fooled.

Where this leaves you

The industry spent a year teaching people to think of agents as teammates with names and roles. That framing helps people delegate. It also hides the question that decides what goes wrong: what does this agent share with every other agent I run?

You can answer that question this afternoon with a spreadsheet. Do it before you connect the next bank account, mailbox or chat workspace, because the agent you give the most sensitive access to is only as contained as the least careful agent beside it.

Sources: Grok Bot FAQ, Grok Bot computer and apps, Grok Bot security, Grok Bot overview, Cybernews, Business Insider, VS Code 1.141 release notes, GitHub Copilot weekly releases.

Medium metadata

Title: Grok Bot's Bank Leak Shows Separate AI Agents Are Not Separate Permissions
Subtitle: Named agents with different jobs feel isolated. On many platforms they share one browser, one credential store and one blast radius.
Tags: AI Agents, Cybersecurity, Artificial Intelligence, Privacy, Automation
Canonical: fervorai.dev