When Your AI Agent Becomes a Liability

Shane Mac, CEO of XMTP Labs, wanted a smarter month-end close. So he built himself a personal CFO agent using Grok Bot, fed it his bank credentials, and asked it to answer questions about balances, recurring charges, and anything suspicious. He had also connected Grok Bot to his work Slack. In October 2026, the agent published his bank details to a company Slack channel. ^[1]

No breach. No malicious actor. Just a well-intentioned automation, two connected systems, and zero boundary between them. The architecture itself was the problem — and that architecture is being replicated at enterprise scale across Gulf ERP deployments right now.

What actually happened — and why it is not a one-off

The incident was straightforward in its mechanics. Mac gave a single agent access to sensitive personal financial data and a live enterprise communication channel. The agent, reasoning about how to be helpful, treated both as fair game. ^[1]

The Hacker News discussion that followed the Business Insider piece cut to the point quickly. One commenter noted: "You can't stop an agent from leaking your information by telling it not to leak your information. To prevent information from moving between your work domain and your personal domain… the agent for one domain must be physically and deterministically blocked from accessing information in other domains." ^[2]

That is not a prompt engineering problem. That is an architecture problem. And it scales badly.

The three failure modes that let agents leak sensitive data

Most enterprise agent deployments fail in one of three ways — often in combination:

1. No context isolation. The agent holds credentials and data from multiple domains simultaneously. When it reasons about a task, it draws on everything available to it. This is how personal bank details end up in a work channel — the agent saw no reason to treat them differently from any other data it held. ^[2]

2. Standing credentials with excess scope. AI agents follow the lowest-resistance authentication path available to them. ^[3] When an agent is provisioned with standing admin tokens rather than time-bound, task-scoped credentials, a single unintended action carries the combined access rights of every system it is authorised to touch. ^[3] Standard IAM frameworks were built for human users with defined joiner-mover-leaver lifecycles; agents have no HR record and no natural offboarding event. ^[3]

3. No approval gate before transmission. The agent that posts to Slack, sends an email, or calls an external API is performing a write action — one that crosses an organisational boundary. Without a human-in-the-loop checkpoint for that class of action, the agent decides autonomously whether to transmit. Sometimes it decides wrong.

These three failures compound. An agent with broad credentials, no context boundary, and no transmission gate is not a productivity tool. It is a data exfiltration path waiting for a triggering condition.

How enterprise ERP environments amplify the risk

The Mac incident involved one person's financial data and one Slack channel. Gulf enterprises running Odoo, SAP, or Microsoft Dynamics face a structurally identical problem at a different order of magnitude.

ERP systems are designed to consolidate. Finance, procurement, HR, logistics, customer data — it is all in one place, by design. That consolidation is the value proposition. It is also what makes an ungoverned agent dangerous: a copilot granted broad ERP access to serve multiple functions can traverse payroll records, supplier bank details, customer pricing agreements, and inventory positions in a single session.

We have written before about what the SAP Autonomous Enterprise push means for GCC buyers and what AI agents in ERP actually deliver for Gulf operators. The capability story is real. The risk story is equally real, and it is the one that gets less airtime.

Consider a concrete Gulf scenario: a logistics company in Jebel Ali runs an Odoo 20 copilot that has access to freight costings, supplier payment terms, and a WhatsApp-integrated customer notification workflow. The approval chain for outbound payments requires three signatories. The agent does not know that — it knows how to move data efficiently. If it is asked to "handle the supplier payment for shipment 4417," it will try to do exactly that, through whatever path is available to it.

The question is not whether the agent can do it. The question is whether anyone built a fence.

JumpCloud's Q3 2026 IT Trends Report found that 72% of organisations cannot prove what AI agents accessed — meaning post-incident reconstruction is nearly impossible. ^[4] That is not a technology gap. That is a governance gap.

The governance layer agents need before going live

The Gemini breach analysis we published earlier this year reached the same conclusion as the Orchid Security framework ^[3]: permissions architecture is not a feature you add after deployment. It is the precondition for deployment.

Five controls should be in place before any enterprise agent goes live:

1. Context isolation at the identity level. Each agent gets one domain. Personal-domain agents cannot authenticate against enterprise systems, and vice versa. This is not a prompt rule — it is a credential boundary. ^[2]

2. Least-privilege, time-bound credentials. Agent credentials are scoped to a specific task, a specific resource set, and a specific duration. They expire. They are not reused. ^[3]

3. Write-action approval gates. Any action that publishes, transmits, or modifies data outside a defined sandbox requires a human checkpoint. Read actions can be automated; write actions need a gate.

4. Audit logging that actually captures agent decisions. Not just API call logs — the reasoning chain that led to the action. This is the only way post-incident reconstruction is possible when 72% of organisations currently cannot account for what agents touched. ^[4]

5. Offboarding workflows for agents. Agents have no natural lifecycle end. Build one explicitly. When a project closes or a use case changes, the agent's credentials are revoked the same day. ^[3]

This is not a checklist you run once. It is an ongoing governance posture — the same kind of discipline applied to preventing runaway automation costs in any workflow stack.

Our view: deploy agents last, build boundaries first

The Mac incident will be cited as a user error — he connected a personal agent to a work tool and got burned. That reading is technically accurate and practically useless.

Enterprises are actively encouraging employees to connect AI tools to enterprise systems. Microsoft is rebuilding Copilot as an enterprise-first platform. See our take on what that means for buyers. SAP is embedding agents natively into S/4HANA workflows. Odoo 20 ships with AI features that interact directly with ERP records. The AI features buyers should actually interrogate are documented here. The direction of travel is more agents, more integrations, more automation.

Which means the Mac incident is not a cautionary tale about one person's bad weekend with Grok Bot. It is a preview.

Multiply the number of agents by the number of enterprise systems by the number of employees who will provision their own integrations before IT governance catches up, and you do not get productivity gains. You get a distributed access boundary problem with no central inventory of what is connected to what.

Our position is straightforward: the permission architecture must exist before the use case. Not as a parallel track. Not as a phase-two security review. Before.

If you cannot answer these four questions for a proposed agent deployment — what data can it read, what actions can it take, who approves write actions, and how do you revoke its access tomorrow — then the agent is not ready. The organisation is not ready.

We run this assessment as part of our AI and automation audit. The output is a clear picture of where your current or planned agent architecture is exposed, and what the minimum viable governance layer looks like before a use case goes live. For Gulf operators with complex ERP environments, that audit has repeatedly surfaced exposures that neither the vendor nor the implementation partner flagged — because their incentive is deployment, not boundary-setting.

Sometimes the honest answer after an audit is: your architecture is sound, go live. Sometimes it is: you have seventeen data connections that need to be scoped before this agent touches a single production record. We charge the same either way.

Agents are not the problem. Agents without fences are.