By NHI Mgmt Group Editorial TeamDomain: Agentic AI & NHIsSource: MintPublished July 1, 2026

TL;DR: Three managed agent platforms now target enterprise buyers, but their documented security boundaries differ sharply across runtime isolation, delegated authority, and governance, according to Mint’s review of Anthropic Claude Managed Agents, OpenAI ChatGPT Workspace Agents, and Google Gemini Enterprise. The governing question is no longer whether agents can work, but what they can reach, under whose authority, and with what evidence trail.


At a glance

What this is: This is a comparative audit of managed agent control planes, and the key finding is that Anthropic, OpenAI, and Google expose materially different security boundaries for agent runtime, authority, and observability.

Why it matters: It matters because identity teams will need to govern agents as privileged automation surfaces, not just model interfaces, and the control plane shape determines what can be approved, monitored, and revoked.

👉 Read Mint's audit of managed agent control planes and security boundaries


Context

Managed agents sit in a governance gap that traditional IAM and PAM models do not fully cover. The primary question is not whether an agent is useful, but whether its runtime boundary, credentials, and delegated authority can be scoped tightly enough for enterprise use across NHI and identity governance programmes.

In this comparison, managed agents behave like privileged non-human identities with varying levels of runtime isolation and policy enforcement. That makes the control plane, not the model name, the object security teams should review first. For lifecycle and rotation context, the NHI Lifecycle Management Guide is the right baseline for how credentials and access should be governed in practice.


Key questions

Q: How should security teams govern managed agents that can access real systems?

A: Treat each managed agent as a non-human identity with explicit authority, runtime bounds, and an audit trail. Governance should cover who can invoke it, which apps or tools it can use, whether its runtime can reach secrets, and how its actions are logged for review. If any of those are missing, the agent is operating outside a defensible identity model.

Q: Why do managed agents need identity governance?

A: Managed agents need identity governance because they can perform actions, access resources, and influence business processes without being human. Once an agent can act, it becomes a governed identity with scope, ownership, and review requirements. Without those controls, teams cannot explain who was responsible for the access or the resulting action.

Q: What do identity teams get wrong about instant approvals?

A: They often focus on transaction speed and ignore whether the approval path still has enough decision points to detect fraud. Instant approvals can be safe only when upstream proofing, consent, and anomaly detection are strong. Without those controls, the organisation may be optimising for conversion while weakening assurance.

Q: Who is accountable when a managed agent takes the wrong action?

A: Accountability should be split across the human invoker, the platform owner, and the system owner that exposed the connected credential or integration. If the organization cannot tell which principal acted and under what policy, then accountability has been designed too loosely for enterprise use. That is a governance failure, not just an operational one.


Technical breakdown

Runtime isolation and session boundaries in managed agents

Managed agents differ most clearly in how they isolate execution. A strong runtime model separates the agent brain from the hands, so the session, sandbox, and harness do not all share the same trust zone. That matters because the agent may process untrusted input while also calling tools, generating code, or touching files. If session state persists, or if credentials are reachable from the execution container, the runtime becomes a privilege container rather than a containment boundary. For practitioners, the key question is whether the platform can prove that secrets never become reachable from the code-execution surface.

Practical implication: Review where credentials live relative to the session container and reject any design where the runtime can directly touch reusable secrets.

Delegated authority, app auth, and agent identity

Managed agents are only governable when the system can say whose authority they use. Some platforms rely on end-user authentication, others on agent-owned or shared credentials, and others on a cryptographic agent identity bound to policy and gateway enforcement. Those choices determine whether actions are attributable to a person, a service account, or a distinct agent principal. The governance difference is material: if the platform cannot distinguish invocation authority from execution authority, then access reviews and approvals become ambiguous. This is where NHI controls and IAM policy models converge.

Practical implication: Map every agent to a distinct authority model and prohibit shared app connections that blur who triggered the action and whose access was used.

Policy enforcement, observability, and evidence trails

A managed agent is only defensible if policy decisions and execution evidence are both available. Good governance includes app or tool approvals, central policy enforcement, audit logs, traces, and observable action results. Without that, security teams can neither reconstruct misuse nor validate whether a policy actually constrained the runtime. The operational issue is not only control coverage, but whether logs can tie user intent, agent invocation, tool usage, and downstream resource access together into one traceable record. That is the difference between oversight and hope.

Practical implication: Require an end-to-end audit trail that links invoker, agent identity, tool call, and resource action before broad rollout.


Threat narrative

Attacker objective: The attacker objective is to abuse delegated agent authority to reach business systems and execute actions that appear legitimate under the agent’s granted access.

  1. Entry begins when a managed agent is granted access to files, apps, or connected tools inside an enterprise workspace or runtime. Escalation follows when the same agent can invoke higher-risk actions through shared credentials, connected apps, or delegated authority that outlives the original user context. Impact occurs when the agent can reach production systems, modify data, or trigger downstream actions without a clearly bounded evidence trail.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Managed agents are now privileged non-human identities, not just AI features. Once an agent can hold credentials, call tools, and leave logs, it belongs in the same governance conversation as service accounts and workload identities. The operational difference is that the agent may also act through a user-facing workspace, which blurs traditional ownership models. Security teams should treat the control plane as the identity object, not the model wrapper.

Runtime isolation is the first governance boundary that determines whether agent risk is containable. Anthropic’s stronger public emphasis on session, sandbox, and harness separation shows why execution boundaries matter more than model capability. If the execution surface can reach credentials, then the platform has already lost the principle of credential non-exposure. Practitioners should prioritise where the agent can execute before they debate what it can do.

Agent identity changes the review model because access is no longer solely person-bound. A cryptographic or workspace-bound agent principal can improve traceability, but only if it is distinct from the human who triggered it and from the connected apps it uses. That distinction matters for recertification, offboarding, and approval logic. Teams should insist on identity objects that can be reviewed independently of the initiating user.

Governance vocabulary is becoming a procurement signal, not a documentation flourish. The presence of terms like agent registry, gateway, semantic governance, and observability tells buyers where the platform expects control to happen. If those controls are still in preview, the operating model is not ready for broad trust. The practical conclusion is simple: do not let naming completeness substitute for enforcement maturity.

Identity blast radius is the concept practitioners should use for managed agents. It captures the spread between what an agent can nominally access and what it can actually reach through connected apps, delegated authority, and session persistence. That spread is the real governance problem in managed agents, and it is what access reviews must now measure. Security teams should design around blast radius, not feature lists.

From our research:

  • 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and another 47% reporting only partial visibility, according to The State of Non-Human Identity Security.
  • Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
  • That confidence gap is why teams should pair managed-agent governance with the NHI Lifecycle Management Guide and separate identity lifecycle from application deployment.

What this signals

Identity blast radius: managed agents should be evaluated by the total reach of their credentials, triggers, and connected tools, not by whether the model is accessible in a workspace. That means agent onboarding needs the same review discipline as any other privileged non-human identity, especially where app connections can silently expand reach.

With 1 in 4 organisations already investing in dedicated NHI security capabilities, the market signal is clear: agent governance is moving from an experimental concern to a programme requirement. Teams that still separate IAM, PAM, and NHI controls will struggle to review delegated authority across agent identity, runtime, and approval paths.

The control question now is whether a platform can prove who acted, under what principal, and with what evidence trail. If that cannot be answered cleanly, the organisation should treat the agent as an unmanaged identity surface until the boundary is fixed.


For practitioners

  • Inventory every managed agent as an identity object Catalogue each agent, its connected apps, its credentials, its trigger paths, and the systems it can touch. Do this before pilot expansion so you can see where delegated authority is already wider than the stated use case.
  • Separate invocation authority from execution authority Require a distinct record of who triggered the agent and which principal it used to act. Block shared connections where a single app-auth path makes human ownership and agent action indistinguishable.
  • Bound runtime reach before permitting production use Review whether the platform exposes sandbox isolation, container egress controls, and secret non-exposure guarantees. If the runtime can reach reusable credentials or unrestricted outbound resources, keep it out of sensitive workflows.
  • Make observability a release gate Require logs that tie user, agent identity, tool call, approval, and resource action into one traceable record. If the control plane cannot reconstruct that chain, the agent should not be allowed into regulated or high-impact processes.

Key takeaways

  • Managed agents are becoming privileged non-human identities, which means identity governance now extends into runtime control planes and delegated authority paths.
  • The biggest risk is not model capability alone, but the gap between declared access and actual blast radius across connected apps, sessions, and credentials.
  • Practitioners should require distinct agent identity, bounded runtime reach, and end-to-end evidence before permitting production use.

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.
  • 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.
  • Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
  • Delegated Agent Authority: The permission granted to an AI agent to act on behalf of a human user or another agent, inheriting some or all of their access rights. Delegated authority must be explicitly scoped, time-limited, and auditable.

What's in the full report

Mint's full audit covers the operational detail this post intentionally leaves for the source:

  • Per-platform control-plane breakdowns for Anthropic, OpenAI, and Google that show exactly where runtime, authority, and governance differ.
  • Documented boundary details on sessions, sandboxes, vaults, approvals, agent identity, and observability that implementation teams need before rollout.
  • Comparative notes on preview versus private-preview features so buyers can assess maturity before building policy around them.
  • The underlying references and documentation trail that support the audit's control-plane comparison.

👉 Mint's full comparison covers the runtime, authority, and observability details behind each managed agent platform.

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 identity security programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org