Managed agent control planes are converging, but boundaries differ

At a glance

What this is: Mint compares how Anthropic, OpenAI, and Google document managed agent boundaries, finding that the control planes are converging while the security models remain materially different.

Why it matters: IAM, PAM, and NHI teams need to judge managed agents by reachable scope, authority, and auditability, because those boundaries determine whether an agent behaves like governed automation or privileged sprawl.

Context

Managed agent platforms are now being sold into the same enterprise use case, but the security problem is not the model itself. The real issue is boundary definition: what the agent can touch, which credentials it can invoke, and what evidence remains after it acts. For NHI governance, that makes managed agents a privileged identity question, not just an AI operations question.

Mint’s comparison shows three different control-plane shapes. Anthropic emphasizes runtime isolation, OpenAI emphasizes workspace delegation and approvals, and Google emphasizes agent identity, registry, gateway, and policy enforcement. Those are not interchangeable security patterns, and a programme built for one boundary model will misread the others.

Key questions

Q: What should security teams check before approving a computer-using agent for production use?

A: They should verify the agent’s authorisation scope, logging quality, escalation path, and review boundaries before it is allowed into a real workflow. A strong benchmark result is not enough. The question is whether the agent can be governed like a production actor, with clear ownership and a record of every meaningful action.

Q: Why do managed agents change NHI governance requirements?

A: Managed agents can use credentials, call tools, and act against business systems, so they behave like high-risk non-human identities. That means IAM and PAM teams must govern reach, authority, and evidence trail, not just authentication. The risk is not the presence of automation, but the absence of a clear boundary model.

Q: What breaks when a managed agent has broad runtime or egress access?

A: The agent's blast radius expands from contained task execution to general-purpose action. When sandboxing and outbound reach are broad, prompt injection, tool misuse, and delegated credential abuse become harder to contain because the runtime can interact with more systems than the governance model assumed.

Q: What is the difference between workspace delegation and governed agent identity?

A: Workspace delegation grants control through the collaboration layer, such as publishing, sharing, or app authentication, while governed agent identity ties the agent to a distinct, inspectable identity and policy path. The first manages who can invoke the agent. The second manages how the agent is recognised and constrained when it acts.

Technical breakdown

Hosted runtime, workspace automation, and governed communication

The three platforms expose different security objects, which changes how control is enforced. Anthropic centers on environments, sessions, vaults, and events, so the runtime itself is the primary boundary. OpenAI centers on workspace publishing, app auth, Slack, schedules, and approvals, so the workspace becomes the boundary. Google centers on identity, registry, gateway, policies, and observability, so communication between agent and resource is the boundary. These are distinct architecture choices, not different labels for the same thing. A security review has to match the enforcement layer to the risk being introduced, or it will miss where authority actually lives.

Practical implication: Map each managed agent platform to the boundary it actually enforces before you compare controls or approve use cases.

Sandboxing and network egress shape agent blast radius

A managed agent becomes dangerous when the runtime can both process untrusted input and reach too far outward. Anthropic documents per-session isolated containers with restricted networking options, including allowed-host controls. Google documents a limited sandbox with no network access for code execution. OpenAI’s reviewed Workspace Agent material is much thinner on the runtime and egress layer, which leaves a gap for reviewers who need to know what the agent can reach once it is running. For managed agents, sandboxing is not a cosmetic architecture detail. It is the difference between a contained session and a general-purpose execution surface.

Practical implication: Treat network egress and sandbox scope as first-order review items, not implementation details left to engineering later.

Delegated authority determines whose permissions the agent is really using

The central governance question is not whether an agent can call a tool, but whose authority it inherits when it does. Anthropic’s vault model separates stored credentials from the sandbox and re-resolves them during a session. OpenAI distinguishes end-user authentication from agent-owned authentication, which is critical when Slack or shared connections can let others trigger the same authority path. Google’s agent identity model is the most formalized, using cryptographic identity, certificate binding, and gateway-mediated access. These are different answers to the same governance problem: delegated authority must be explicit, bounded, and attributable.

Practical implication: Review every managed agent as a delegation chain and require the authority path to be visible before production use.

NHI Mgmt Group analysis

Managed agents are becoming privileged automation surfaces, not just AI features. The comparison shows that enterprise buyers are evaluating systems that can act with business context, tools, and credentials, which places them in the same governance frame as other high-risk non-human identities. The practical conclusion is that agent security has to be reviewed as identity governance, not as model evaluation alone.

Boundary shape now matters more than model quality for security review. Anthropic, OpenAI, and Google are converging on the same buyer, but they expose different enforcement layers: runtime, workspace, and governed communication. That means programme teams cannot assume one set of controls transfers cleanly across platforms. The practitioner implication is that control testing must follow the boundary model, not the marketing category.

Managed agent control planes are not yet a common security standard. Google’s formal vocabulary, Anthropic’s runtime detail, and OpenAI’s workspace governance each illuminate different parts of the problem, but none creates a universal approval baseline. That leaves organisations with an integration and audit problem, because the evidence needed to justify delegated access is fragmented across products. Security teams should expect platform-specific governance, not portable assurance.

Authority transparency is the decisive governance issue. The key question is who can trigger the agent, what credentials it uses, and what scope those credentials carry when the agent acts. In NHI terms, that is a delegated authority problem with audit consequences. The practitioner conclusion is that identity teams need a policy for agent ownership, invocation, and evidence retention before agents become embedded in daily work.

Managed agent boundaries are now a procurement issue as much as a runtime issue. When one platform emphasizes isolation, another emphasizes approvals, and a third emphasizes identity and gateway policy, the buying decision becomes a governance decision. That shifts the burden onto IAM, PAM, and security architecture teams to define minimum boundary evidence up front. The field is moving toward managed agents, but assurance is still fragmented.

What this signals

Managed-agent governance will increasingly sit between IAM and AI operations. Teams that already own service account governance, approval workflows, and access evidence are the ones best positioned to evaluate these platforms. The next programme step is not just to approve agents, but to define which boundary model your organisation can actually support.

Boundary evidence will become the procurement filter. Security buyers will increasingly ask not whether a platform can run an agent, but whether it can prove containment, authority, and observability in a way audit teams can consume. That shifts evaluation from feature comparison to control validation.

Runtime isolation still matters, but it is no longer sufficient on its own. Managed agents also need explicit delegated authority and durable evidence trails, otherwise the organisation cannot explain what happened after the fact. The practical result is a combined review of sandboxing, identity binding, and event logging.

For practitioners

• Define the agent boundary model first Classify each managed agent as runtime-isolated, workspace-delegated, or gateway-governed before allowing production use. The review should identify where policy is actually enforced and where the platform only records activity after the fact.
• Test delegated authority paths Document whether the agent uses end-user credentials, shared agent-owned credentials, or cryptographically bound agent identity, then verify who can trigger the action path and under what scope.
• Review sandbox and egress controls Confirm whether the agent runtime can reach the internet, approved hosts, MCP servers, or only a restricted sandbox, and require explicit sign-off for any outbound path that expands blast radius.
• Verify approval and publishing governance Check which actions require approval, who can publish the agent, and whether Slack or directory sharing expands the invocation surface beyond the intended operator group.
• Establish evidence retention for agent actions Require logs that show invocation source, identity used, tool access, and outcome so that audits can reconstruct who acted, through which control plane, and against which resource.

Key takeaways

• Managed agents are converging as a category, but the security boundaries behind them are not converging at the same pace.
• The most important comparison is not model capability. It is the platform's boundary model for runtime, authority, and observability.
• IAM and PAM teams should require documented evidence of containment and delegated authority before managed agents move into production.

Key terms

• Managed Agent: A managed agent is a software identity that performs tasks on behalf of an organisation and must be governed like any other non-human identity. In practice, it needs an owner, a defined access scope, and reviewable entitlements so its actions can be traced and controlled.
• Delegated Authority Model: A delegated authority model defines who is allowed to approve, review, or execute control-related decisions across the enterprise. It helps ensure requests reach the correct responsible party, especially when control owners, managers, and process owners sit in different teams, regions, or systems.
• Sandbox Boundary: A control boundary that separates untrusted execution from sensitive systems, data, and credentials. For agentic development, the boundary must cover both what the code can read and what it can call externally, otherwise a sandbox can still reach production through outbound requests.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity governance programme, it is worth exploring.