What the Composio Breach Should Change About How We Run Agents

TL;DR

• Securing the execution sandbox is the wrong perimeter. The Composio breach succeeded because the container could reach arbitrary external endpoints after execution, not because execution was uncontrolled.
• Exfiltration blocked at the network layer ends the kill chain at step four. Everything before that becomes a foothold that goes nowhere.
• The correct frame: secure the exit. Execution containment is downstream of that.
• Local coding agents with unrestricted egress collapse every boundary the Composio attackers had to move through. The architecture failure isn't unique to production.

There's a mental model most teams carry into agent security, and it's subtly wrong.

The instinct is to lock down execution - restrict what the agent can run, treat the sandbox as the perimeter. It feels right because execution is where the model stops talking and starts doing. Contain that, and you feel like you've contained the risk.

Last week, Composio published a breach disclosure that stress-tests exactly that assumption.

The Kill Chain

Foothold in an internal monitoring agent → lateral move via implicit trust to a remediation system → malicious tool definitions registered in the execution sandbox → arbitrary code execution → 5,241 API keys and 5,001 GitHub OAuth tokens pulled from an auxiliary cache and exfiltrated to commercial VPN endpoints.

The sandbox worked. Code ran in it. That wasn't the failure.

The failure was that after execution, the container could reach arbitrary external endpoints. Secrets were reachable. The path out existed.

If exfiltration fails at the network layer - enforced outside the container, outside the agent's trust boundary, that kill chain ends at step four. Code execution in a box that can't talk to anything interesting. The attacker has a foothold that goes nowhere.

The reframe: don't secure execution, secure the exit.

What Securing the Exit Actually Looks Like

We run an on-call assistant in production with read access to our observability stack. Same scope profile as Composio's monitoring agent. The container executes whatever it needs to. What it cannot do is reach anything outside this:

Three destinations. Enforced at the proxy layer, not the application layer — because application-layer controls sit inside the trust boundary the attacker already occupies. Proxy-layer controls do not.

Everything else follows the same principle — push the control outside the boundary:

• Credentials injected per-session at the proxy layer, outside the container. The agent never holds secrets. Can't exfiltrate what it was never given. This pattern aligns with how token vaults isolate credentials from agent runtime.
• Pre-tool hooks reject before the LLM executes anything. The model never does what it shouldn't. This is tool calling authentication applied at the enforcement layer, not the agent layer.
• Host filesystem unreachable by construction, not policy. Policy can be negotiated. Construction can't.
• MCP servers reviewed before connection. They run with the agent's full privileges — the trust model is identical to a dependency you'd vendor. Treat it that way. If you're shipping MCP servers, stop shipping them unsecured.

This isn't a novel architecture. It's what you'd build for any CI runner touching production. The shift is applying the same thinking to agentic workloads, which most teams still aren't doing.

Local Is Where It Gets Uncomfortable

If your coding agent runs in yolo mode — full shell, live cloud session, personal GitHub token, unrestricted egress — you've already collapsed every boundary the Composio attackers had to move through.

Recommended Reading: Composio got breached in production. If your team is re-evaluating its stack, see how Scalekit compares against Composio. The patterns that defend production agents are the same patterns that should defend local ones.

A prompt injection in a README or a hostile MCP server is your initial access vector. There's no step two. You're at credential harvest.

That's not carelessness. It's the same mental model problem. "I'm the one running this" feels like sufficient trust when you're in a shell. It isn't when the agent is ingesting and acting on arbitrary external content — which is every coding session the moment it touches a repo.

The MCP security risks in the enterprise apply equally to local development environments. If an agent has access to long-lived tokens with no scope boundaries, the blast radius is identical whether the breach happens in production or on a developer's laptop. Understanding who holds the token across different tool-calling patterns is what separates recoverable incidents from catastrophic ones.

The Architecture Failure Isn't Unique to Production

Composio got breached in production. But the failure it exposes isn't a production-only problem.

The patterns that defend production agents are the same patterns that should defend local ones. Secure the exit. The rest is downstream of getting that right.

When your IAM setup doesn't cover AI agents, the gap exists everywhere agents run — not just in production clusters. Whether you're building access control for multi-tenant AI agents or running a single coding assistant locally, the principle is the same: the security perimeter is the network boundary, not the execution sandbox.