TL;DR: PlainID argues that sandboxing AI agents is not enough once they connect to MCP tools, APIs, databases, and business workflows, because runtime authorization must decide what users and agents can access, retrieve, invoke, and expose. Sandbox containment reduces infrastructure risk, but it does not resolve the trust assumption that action can be safely deferred until after execution starts.
At a glance
What this is: This is a PlainID analysis of runtime authorization for AI agents, showing that sandboxing alone does not govern what agents can do once they reach enterprise systems and tools.
Why it matters: It matters because IAM teams must control agent access, tool invocation, and data exposure at the point of action, not just isolate execution environments.
👉 Read PlainID's analysis of runtime authorization for AI agents and OpenClaw
Context
AI agent runtime authorization is the control layer that decides, at the moment of execution, what an agent may access, invoke, retrieve, or expose. The article argues that once agents move from isolated testing into enterprise workflows, sandboxing no longer answers the governance question that matters: who or what is allowed to act, and under which policy context.
For IAM and security teams, the issue is not whether the agent can run safely in a container. It is whether the enterprise can enforce identity-aware decisions across users, agents, MCP tools, APIs, and data sources as those interactions happen. That makes runtime authorization a governance problem, not just an application control problem.
Key questions
Q: What breaks when AI skills are allowed to run without sandboxing?
A: Without sandboxing, a skill is no longer a bounded feature. It becomes local code with access to the shell, filesystem, credentials, and outbound connectivity, which makes malware delivery and secret theft materially easier. The control failure is not just technical isolation, but the assumption that an extension can be trusted after install.
Q: Why do authenticated users still need separate controls for AI agents?
A: Authentication confirms the person is known, but it does not decide which agent they may use, which tools that agent may invoke, or what data can be exposed. Agentic systems create a second decision layer that must be governed independently because the user’s identity and the agent’s actions are not the same control problem.
Q: How can organisations tell whether runtime authorization is actually working?
A: Look for three signs: decisions happen fast enough to stay inline, policies use live context instead of stale claims, and every allow or deny produces an auditable record. If teams cannot explain a specific decision after the fact, or if applications bypass the control because it is too slow, the runtime layer is not functioning as intended.
Q: How should organisations handle AI agent permissions in authorization systems?
A: Treat AI agents as task-bound actors, not as full substitutes for the user whose session launched them. Every agent action should be checked against the minimum resource scope required for that task, because inherited human permissions are usually broader than the workflow needs.
Technical breakdown
Why sandboxing stops at containment
A sandbox isolates the execution environment, but containment is not authorisation. In the article’s model, an agent can still reach internal databases, MCP tools, APIs, RAG systems, SaaS applications, and business workflows once the environment is connected to enterprise resources. At that point, the security question shifts from runtime safety to runtime permission. Authentication proves who logged in, but it does not decide whether the agent may access a tool, read a table, or expose a response. Practical implication: control must move from environment isolation to action-level policy enforcement.
Practical implication: Treat sandboxing as containment, not authorisation, and enforce tool and data permissions at the moment of agent action.
How runtime authorization governs agent-tool decisions
Runtime authorization evaluates the user identity, agent identity, requested tool, and context before the action is allowed to proceed. That is different from prompt filtering or post-generation review, which only inspect the request or output after the decision path has already begun. The article’s demo shows an authorized user can use one agent while being blocked from an HR agent or from invoking a restricted SQL MCP tool. That pattern matters because the policy boundary sits on the action itself, not just the interface. Practical implication: align policy evaluation with the tool call, not the chat response.
Practical implication: Bind policy checks to each tool invocation and data request so the control fires before the agent acts.
Why agent identity and user identity both matter
The article describes two deployment modes: principal context mode, where both user and agent identity shape the authorization decision, and agent-only mode, where policy is applied directly to the agent. That distinction matters because enterprises do not govern all agents the same way. Some are user-facing assistants, while others are background or system-to-system actors. If the policy model assumes only one identity, it misses the full delegation chain. Practical implication: define whether access decisions follow the human, the agent, or both before production rollout.
Practical implication: Decide whether your authorization model is user-centric, agent-centric, or combined before you expose agents to production systems.
Threat narrative
Attacker objective: The objective is unauthorized access to enterprise data and business actions through an AI agent that is not properly constrained at runtime.
- Entry occurs when a user or agent reaches enterprise systems through a sandboxed AI workflow that still has live connections to tools and data sources.
- Escalation happens when the agent can invoke MCP tools, query databases, or call APIs without a runtime policy check tied to identity and context.
- Impact follows when the agent retrieves restricted information or exposes sensitive data in a final response despite the environment appearing contained.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Sandboxing is the wrong control boundary for agentic systems: it contains the runtime environment, but it does not decide what an AI agent may do once connected to enterprise tools and data. That assumption was acceptable for isolated experimentation, yet it fails the moment the agent becomes operational. The practical conclusion is that identity governance must move from environment containment to action authorization.
Runtime authorization is the missing policy layer for agentic workflows: authentication answers who logged in, while runtime authorization answers what that identity may access, invoke, retrieve, or expose at the point of action. That distinction matters because agentic systems turn tool use into a live decision stream. Enterprises that blur those layers end up with policy that looks present but does not govern execution.
Agent identity and user identity are now separate governance objects: the article’s principal-context and agent-only modes show that some decisions must be evaluated against both identities, while others are agent-scoped alone. This breaks the old assumption that one authenticated user context is enough to govern downstream access. Practitioners need a delegation model that survives user, agent, and tool combinations.
Identity blast radius is determined by runtime context, not container boundaries: once an agent can reach MCP tools, APIs, and business workflows, the real risk is how far that identity can move inside the session. The named concept here is identity blast radius, meaning the scope of actions and exposures an agent can create before the system re-evaluates permission. That is the governance variable teams need to measure.
Access review alone cannot govern ephemeral agent actions: if a policy only certifies who should have access in general, it misses the moment when an agent chooses a tool and executes it. Runtime authorization shifts control to issuance and invocation time, which is where agentic behaviour actually occurs. That is the correct control plane for production AI workflows, not post hoc review.
From our research library:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Identity Security Buyer's Guide
What this signals
Governance programmes built for human users cannot assume an agent will wait for the next review cycle before taking action. Runtime authorization makes permission a live decision, which means the control point moves from periodic certification to each tool invocation and each data request.
Identity blast radius: the meaningful unit of control is no longer the container or the chat session, but the scope of what an agent can reach before policy intervenes. That scope expands quickly when agents can touch MCP tools, APIs, and business systems, so teams need to measure access at the action boundary, not the environment boundary.
For practitioners
- Define the authorization boundary at tool invocation Require policy evaluation before each MCP tool call, database query, or API action so the agent cannot execute first and ask later.
- Separate user, agent, and tool entitlements Model the authenticated human, the AI agent, and the target resource as distinct policy subjects so permissions do not collapse into one shared context.
- Classify which workflows need principal context Use combined user-plus-agent context for interactive assistants and agent-only policy for background automation or system-to-system agent flows.
- Restrict data exposure at response time Block sensitive fields from final outputs when the requestor lacks permission, even if the agent could retrieve the underlying data for a legitimate purpose.
- Measure policy drift across connected tools Track where sandboxed agents can still reach internal databases, SaaS apps, or APIs without a matching runtime control, and close those gaps before production expansion.
Key takeaways
- Sandboxing reduces infrastructure exposure, but it does not govern what an AI agent can do once it connects to enterprise tools and data.
- Runtime authorization moves the control point to the moment of action, which is where agentic access risk is actually created.
- Enterprises need separate policy treatment for users, agents, and tools if they want to prevent unauthorized data access and exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centers on controlling what agents and users may do at runtime. |
| Recommendation — Apply ASI03 to bind agent actions to explicit, context-aware authorization decisions. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The post distinguishes authentication from runtime authorization for AI agents. |
| Recommendation — Separate authentication from action approval so agent access is decided at invocation time. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Runtime policy enforcement is the core control theme in the article. |
| Recommendation — Use PR.AA-05 to govern agent entitlements at the point of access and tool use. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | The article discusses service and agent-to-tool interactions that need identity-aware controls. |
| Recommendation — Apply IA-9 where agents authenticate to tools and services as non-human actors. | ||
| NIST Zero Trust (SP 800-207) | Continuous Verification — Continuous Verification | Runtime authorization mirrors Zero Trust's need to reassess access during execution. |
| Recommendation — Enforce continuous verification before each agent tool call or data retrieval. | ||
Key terms
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- 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.
- Principal Context: Principal context is the verified identity and relationship data used to decide whether a request is legitimate. It tells the authorization system who is actually involved, what account or resource is in scope, and whether the action matches entitlement at the moment of decision.
What's in the full article
PlainID's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step walkthrough of the OpenClaw plugin flow across Keycloak authentication and PlainID policy decisions
- Demo specifics for blocking HR agent access and SQL MCP tool invocation in the runtime path
- Deployment mode detail for principal context and agent-only authorization models
- Practical examples of how runtime policies change agent behavior across users, agents, and tools
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 programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org