Something this quarter is easy to miss because it arrived from three different directions at once. Microsoft product strategy, Cloud Security Alliance framework analysis, and independent security research collectively point toward the same constraint: enterprise adoption is increasingly limited by control, not capability. Each direction exposes a boundary. The useful question is which one.
The convergence
Microsoft made governance the gate. In its enterprise-agent push, the framing is explicit: capability is table stakes, and control is what stands between a pilot and a deployment. Forbes described the stack as a control plane for agents, comparable to what Kubernetes became for containers. Forbes' analysis also identified the architectural limit: Microsoft's controls are strongest inside Microsoft's ecosystem, while most enterprises run agents across several platforms. The control plane is real. Its reach ends at the vendor's edge.
The Cloud Security Alliance mapped the framework gap. Its research note argues that today's governance frameworks, including NIST AI RMF, ISO 42001, and the EU AI Act, do not yet provide a complete set of enforceable, agent-specific controls. Those frameworks assume behavior can be characterized at deployment time and reviewed by a human, an assumption autonomous agents break by operating at machine speed. CSA also names the shape of the gap: principal-level complexity from orchestrator-to-subordinate architectures and authorization cascades, which traditional security models were not built to represent.
Researchers started testing the controls themselves. BeyondTrust's Phantom Labs showed that AgentCore's Code Interpreter sandbox, configured for no external network access, could still resolve DNS, enough to tunnel a command-and-control channel out of a supposedly isolated environment (AWS has since remediated that path). Unit 42 and Sonrai published adjacent findings on the same surface, including network-isolation bypasses, credential-exfiltration paths, and overly broad starter-toolkit permissions that AWS subsequently clarified were unsuitable for production. These are not one control failing the same way. They are evidence that vendor-local controls need independent adversarial validation before an enterprise trusts them.
Two different control problems
Read together, these expose two problems that are easy to blur and important to separate.
The first is integrity: does a control actually hold at the boundary it claims to enforce? A sandbox that promises no egress and then resolves DNS is an integrity failure.
The second is composition: do multiple controls, each working correctly, add up to the constraint the enterprise actually cares about? The second cannot be solved from inside any one vendor-owned unit.
The sandbox research tested the first. I ran a test of the second.
When every local control works and the aggregate constraint is still absent
AWS Bedrock AgentCore Payments enforces a spend limit per payment session. I created five concurrently active sessions under the same principal, each capped at five cents, and drove each to a signed payment authorization.
Nothing escaped a sandbox. Nothing bypassed authorization. Nothing exceeded a configured session limit. Every local control worked exactly as designed. Each session enforced its own budget, and I found no configuration surface for a principal-wide one. The gap appeared only when the five valid sessions were evaluated together: each authorization was decided independently, so session enforcement never added up to principal enforcement. Full method and evidence here.
This is a subtler result than a bypass, and a more useful one. The control is not defective. It is scoped to the session, and the enterprise holds risk at a wider scope. AWS documents the session as a scoped context, so this is composition, not a broken promise.
The honest boundary of the experiment: it demonstrates a composition gap inside one vendor and one API. It does not prove cross-vendor composition. But it earns the inference. If authority does not compose across five sessions inside a single service, an enterprise should not assume it will compose across multiple agents, wallets, gateways, and clouds. That broader conclusion is an architectural inference, not something this one experiment establishes.
The missing layer
The obvious fix for each of these is a better version of the same thing. A tighter sandbox. A bigger session cap. A per-vendor governance console. All necessary. All of it stops at the boundary.
The enterprise does not hold risk only per session, sandbox, or vendor. It may hold cumulative risk per principal, customer, process, tenant, or legal entity, across every agent, wallet, tool, and vendor involved. A control that governs the unit it owns is not aggregate governance. It is a bigger unit.
Every vendor is building a control plane for the unit it owns. The layer that composes authority across those units cannot be supplied from inside any one of them.
Enterprise agent governance has four working parts. Identity governance answers who or what is acting. Access governance answers what systems and tools it may reach. Decision governance answers whether an action is permissible in the present context. Evidence governance answers whether the authorization, the attempt, the outcome, and the cumulative state can be reconstructed.
Composition is not a fifth governance silo. It is the requirement that identity, access, decision, and evidence governance remain coherent across sessions, agents, tools, wallets, vendors, and time. No control plane operating inside one of those units can establish that coherence alone. That is the difference between governance as a product feature and governance as an enterprise system.
Top comments (0)