CFO Agent, Wrong Channel: How an AI Sent a Bank Audit to the Company Exec Slack

A bank audit report walked through the wrong door

Thursday, October 1. Shane Mac, CEO of XMTP Labs, was at work when a DM popped up on Slack — from his head of product: "heads up."

He opened the company Slack channel and found the last thing he'd ever want his colleagues to see: a complete personal monthly financial audit. Checking account balance, savings account balance, the month's biggest expenses — including construction costs for a barn on his own property. The sender showed as himself. The real author was an agent he'd built with Grok Bot at the end of August, which he'd named "Personal CFO."

Days later, Mac opened his account of the incident on X: "Embarrassed to share this, but it scared the shit out of me. Last Thursday, an AI agent posted my personal bank balances into our company Slack. As me."

This is the October agent-safety incident most worth reading closely: no prompt injection, no hacker, no hallucination — the agent did "exactly what I told it to do," and simply delivered the report to the wrong place. The cost of that misdelivery: the CEO's bank statement sitting in the executive channel, in front of his colleagues.

How the agent walked through the wrong door

Mac's as-told-to account for Business Insider (published October 9) lays out the configuration plainly, and nearly every line reads as textbook "looks fine": a CFO agent built at the end of August, with read-only access to his bank accounts; instructions to "run a monthly audit and send it only to me through Grok Bot." He added a detail for The Wall Street Journal: he had a second Grok Bot agent connected to his work Slack, named "Chief of Staff."

The Grok team's post-incident investigation came back with two layers. The surface cause: destination confusion. Mac's personal agent group chat and the company's real executive channel were both called "Exec-team" — identical names, and the agent picked the wrong one. "The CFO agent got the channel wrong because the channels had the same name."

The deeper cause is the one every agent builder should remember: these agents look like independent "colleagues" on the surface but share one set of connections underneath. Mac's own words: "It was read-only, and this specific Grok Bot agent didn't have Slack. But another one did. Turns out, they're all connected." SpaceXAI's documentation actually says it outright: "The computer is assigned to your user account, not an individual Bot. Do not place a credential or file on it if another Bot on your account should not be able to use it." The docs also warn: "Do not use separate Bots as a security boundary."

In other words: Mac thought he was commanding a "personal executive team," each agent minding its own job; in reality they were one person wearing different name badges, sharing the same pair of hands. Read-only access locks down "what it can see," while the Slack connection was another agent's "hand" — borrowed the moment the agent needed to send a message.

This diagram compresses the whole chain of events:

"Read-only" governs seeing, not sending

The meatiest lesson of this incident is Mac's own summary line: "It was read-only…" — he assumed read-only meant safe. The security blog AgentAdmit translated that into plain language: "Read-only access limits what an agent can take in. It says nothing about where the agent can send what it has read."

This is the dimension of permission design that vibe coding developers most easily overlook: when we hand out connections, API keys, and file permissions, we habitually think about "what it can touch" and rarely about "where what it touches can flow." For an agent, "read the bank" and "post to Slack" are two independent actions requiring two independent authorizations. Mac's CFO agent ended up with both — the first he granted by hand, the second the architecture handed over "as a convenience."

More troubling is the "nobody prompted it" part. Mac wrote on X: "The scariest part is that nobody prompted it… They act without being asked." That is the selling point of proactive agents — and their original sin: the monthly audit is a scheduled task, so the agent works when the hour comes and sends when it's done, with no human nod anywhere in the loop. The WSJ put it precisely: when an instruction is ambiguous, or there are many ways to execute the requested action, mayhem might ensue. And "send the report to Exec-team" is exactly ambiguous when two same-named channels exist.

Stating it plainly: the incident itself is disputed

As a matter of practice, disputes go on the table, not under it. After the X thread went up, another user relayed a Community Note calling it "engagement farming" and claiming Mac used the second half of the thread to advertise a tool he sells. Mac himself replied: "not fake at all, genuinely happened."

Here is the factual picture as it stands: Mac has told the story himself three times (the X thread on October 6, the Business Insider as-told-to on October 9, the WSJ interview around October 10), with details consistent across tellings; SpaceXAI had not confirmed the incident as of October 7; the misfired Slack message and related logs were never published. Futurism, reporting on it, wrote "we were unable to independently verify his claims," and noted that Mac is building an AI tool for setting rules for agents — the very conflict of interest the Community Note alleged.

So the honest framing is: this is an incident "as told by the person involved," publicly disputed and lacking independent corroboration. But two things are not discounted by the dispute. First, SpaceXAI's own documentation states in black and white not to treat separate Bots as a security boundary, and that connections are shared at the account level — that architectural risk is real regardless of whether this incident happened. Second, failure modes like "read-only doesn't govern sending" and "same-named channels get mixed up" hold in any agent system with multi-destination sending ability. The lessons don't need this incident to be 100% true to be worth learning.

The vendor shipped a fix — but who is responsible

According to Mac, the Grok team shipped a fix the night before the Business Insider piece ran: before an agent moves information across channels, it must have the user's explicit authorization. "Grok realized that users must explicitly grant permission to their agents before those agents can move information to other channels. They implemented and shipped a solution last night."

Mac's own response was more drastic: "After the incident, I removed all my connections. I disconnected Google, my calendars, my banking, Stripe, everything."

The interesting counterpoint is Elon Musk's earlier promise. On August 27, when someone debated whether to connect their bank to Grok Bot, Musk replied "Try it out," adding: "If Grok Bot makes a mistake with a purchase or leaks your card (never happened yet), SpaceX will make you whole." Mac later admitted that line was part of why he dared to connect his bank: "Elon even said to connect your bank account to Grok Bot and promised to make us whole if it lost our money." But every vendor's terms of service walk a different road: Grok's, Meta's, and OpenAI's agent terms broadly agree — what your agent does in your name is your responsibility. A promise is a sentence on social media; terms are a signed contract.

So when an agent screws up, whose fault is it? This incident offers a layered answer: users own their configuration — Mac concedes it himself: "A common response is 'you set it up wrong.' I did." But "setting it up wrong" presumes the system gave you the chance to: same-named channels with zero warning, cross-agent connections shared by default, sensitive sends requiring no confirmation — those are the vendor's architectural choices, not the user's. Selling you "every Bot is an independent colleague" while underneath it's one actor playing many roles — that mismatch between interface and architecture is at least half the vendor's.

Mac's incident wasn't October's only agent misfire

Part of why Mac's story caught fire: it wasn't an isolated case. The same WSJ piece packed in three more scenes of "agents acting on their own," each chilling enough for vibe coding readers.

Annica Benning, a San Francisco communications professional, uses an agent from a small startup, Instinct, to shop, hail rides, and book flights. She returned a swimsuit and asked the agent to find alternatives; the agent sent her a link to approve its selection — she says she never approved it, yet received an order confirmation email. "Anything you do with a credit card, it sends you an approval link," she said. "But because this was store credit, not a credit card, it was able to bypass the approval link." The bikini is on its way; she's hoping it's returnable.

Shalini Dinesh, who lives in Austin, let Meta's Muse organize her son's 13th birthday party at a paintball venue. The agent nailed the invitations, release forms, restaurants, and goody bags — then fumbled the seemingly easiest part, the RSVP list: two invited children shared a first name, and the agent smooshed them into one. "It was looking for exact keywords," she said. "There is no 'Oh great, see you there.'"

And a detail worth savoring: someone asked Claude whether a more powerful agent could manage his kids' schedules while preserving privacy. Claude's answer was to suggest hiring a "household manager" — a part-time human. "The build will take months of your attention." Even the model knows some judgments aren't worth automating.

Taken together, these cases pin down what the Mac incident really is: not a story about "too much bank access," but about "nobody watching the send action." The swimsuit-buying agent had a confirmation step (store credit just bypassed it); the party-planning agent had human review (the list could be fixed); Mac's CFO agent was a scheduled task firing straight through — the send itself had no human in the loop. That is the essential difference between proactive agents and ordinary chatbots, and the WSJ nailed it: users ask agents to carry out tasks, and the agent breaks the prompt down into a series of steps "which are for convenience often not spelled out to the human it's working for." Opaque steps, uncontrolled sends.

Five practical rules for vibe coding readers

If you also wire agents to banks, email, or Slack (or are about to), treat these five as a checklist:

1. One identity and one set of credentials per agent. Don't let "looks like two agents" become "actually shares one set of connections." On any platform whose docs say connections are account-wide, assume they're shared by default and add your own isolation.

2. Authorize reading and sending separately. "Read-only bank access" is not "only send to me." Every outbound channel is its own authorization: what it can read, where it can send, whether a human must approve first — configure the three separately.

3. Sensitive sends get a human review (human-in-the-loop). Scheduled tasks plus automatic sending is the most dangerous combination. Money, privacy, posting to shared channels — these three categories get a confirmation step by default, annoying or not. In Mac's incident, the report sat in the channel for a good while before his head of product spotted it; one pre-send confirmation would have prevented all of it.

4. Treat channel and group names as addresses, not nicknames. Two "Exec-team"s are two identical street numbers. Give agents destinations by unique ID or full path, not human-chosen display names that can collide; sweep for duplicates regularly.

5. Run it once on fake data. Before connecting a real bank, run the full flow on fake accounts and fake balances, and watch with your own eyes where the report lands and whose name it carries. Mac's CFO agent ran fine week to week — the very first monthly audit is what blew up. Low-frequency tasks need rehearsal the most.

Back to that opening line: "Be careful of the dark side of proactive agents." The dark side isn't in model hallucinations — it's in the defaults you assumed were true and weren't: the isolation you thought was architecture was an interface convention; the read-only you thought was safe only governed reading; the "send to me" you configured became "send to everyone." Vibe coding made "build a CFO" a ten-minute job. The "doesn't blow up" part was never a ten-minute job.