Read-Only Banking, Write Access to the Wrong Audience

Shane Mac gave his personal finance agent read-only access to his checking and savings accounts. According to his account published October 9 in Business Insider, its October 1 monthly audit landed in his company's executive Slack chat. The report included his savings balance and biggest expenses. A colleague initially mistook it for company financials, until a barn on Mac's property made the accounting rather more personal.

The permission had a legitimate purpose: let the agent inspect balances, recurring expenses and suspicious activity without changing the underlying accounts. That restriction did not settle who could receive its conclusions. Reading sensitive information and distributing a report are different operations. In Mac's telling, the agent completed enough of the assignment to produce precisely the material he did not want his colleagues reading. An accurate financial assistant can still be an exceptionally inconvenient publisher.

For CTOs, the useful distinction is between protecting the source and controlling the output. Read-only access answers whether an agent may modify bank records; it does not, by itself, answer where the resulting audit may go. Mac says he had instructed the agent to message only him through Grok Bot. The reported disclosure makes that gap concrete: the intended audience existed in his instructions, but the report reached another audience. The deployment question is therefore sharper than whether the assistant has too much access. Which operation does each permission actually constrain?

Mac's explanation is more useful than a diagnosis of an AI suddenly going rogue. He says he connected Slack for one agent, while the different agents underneath their separate presentations shared the same connections. He attributes the mistaken delivery to confusion between similarly named executive chats. That is his account of the investigation, published as an edited first-person essay in Business Insider, rather than an independent technical audit of the routing failure.

The important architectural detail is the shared integration. A personal finance assistant and a work assistant can feel like separate colleagues while possessing access through the same underlying connections. Naming one the CFO does not establish a permission boundary. An organizational chart is an excellent way to explain responsibilities to humans; apparently it can also be decorative upholstery over a common set of capabilities.

Mac reports that Grok subsequently shipped a change requiring explicit permission before agents move information to other channels. That addresses the relevant kind of authority: permission to use a destination, rather than permission merely to read an input. His account does not establish how effectively the change enforces that distinction, but it is a material response, not grounds for pretending controls cannot help. Mac nevertheless disconnected his banking, calendars, Google, Stripe and other integrations. For a deployment review, the resulting question is concrete: when one assistant gains a connection, which other assistants can use it, and who authorizes their recipients?

Microsoft is offering a concrete mechanism for another part of this problem. In October 8 reporting, CNET describes Microsoft Execution Containers as generally available, with configurable file and network access. Its Recommended preset includes internet access and limited access to locations such as Documents, Downloads and Desktop. That is meaningful delegated access, even when the interface has helpfully recommended it for you.

Microsoft's October 7 technical explanation supplies the mechanism behind containment. Developers declare resources, and the policy remains outside the workload's control. In its coding example, an agent can modify a website repository and read server configuration without being authorized to change that configuration. The boundary is designed to block the unauthorized write regardless of what the model or generated code decides would finish the job fastest. The model can propose a shortcut; it cannot promote itself to administrator of the shortcut.

That is a useful complement to the destination problem, with a specific limit. MXC's file and network policies govern access to resources; Mac's account concerns a report sent through a shared messaging connection. Allowing a workload to reach a service leaves a further question about what it may do inside that service and whom it may address. Microsoft's description supports externally enforced resource boundaries, not a claim that MXC would have prevented this Slack incident. The two cases belong together because they identify different decisions in delegated authority: which resources an agent can reach, and which recipients can receive what it learns.

Even a declared boundary needs its operating mode read carefully. Microsoft's technical documentation says Learning mode blocks ungranted operations and records them in a JSON activity report. Permissive mode records access that the MXC policy would deny but lets the operation continue, subject to other applicable restrictions. These policy-authoring modes answer a different question from the access presets: whether an attempted operation is stopped or merely documented.

That distinction changes how an engineer should interpret a successful run. A workload completing in Permissive mode can help identify the resources it needs; completion does not show that it stayed within the proposed MXC policy. Learning mode offers a different trade-off: discover missing permissions while retaining the boundary. An impressive report of prohibited activity is useful during policy development. It is less comforting if the prohibited activity has already completed. The log is not retroactive containment.

The same documentation describes Intune management for MXC-integrated process containers on Windows 11 as forthcoming. Teams should therefore review the controls their actual deployment can enforce today. Taken alongside Mac's account, the practical review has three concrete objects: shared connections, authorized recipients and the mode that governs denied operations. Ask who owns each boundary and what happens when the agent attempts to cross it. A personal executive team may be a useful interface. Its permission model should be more rigorous than its org chart.