Runtime authorization for AI agents: why sandboxing is not enough

At a glance

What this is: PlainID argues that AI agent security needs runtime authorization, not just sandboxing, to control access to tools, data, and outputs.

Why it matters: This matters because IAM teams must govern AI agents as operational actors that can bypass static access assumptions across NHI, autonomous, and human identity programmes.

👉 Read PlainID's analysis of runtime authorization for OpenClaw agent security

Context

AI agent runtime authorization is the policy layer that decides what an agent can do at the moment it acts. The article argues that sandboxing can isolate execution, but it does not answer the harder identity question: which users, agents, tools, data sources, and outputs are allowed inside the same workflow.

That gap matters to IAM and NHI programmes because AI agents are increasingly connected to enterprise systems that were designed around stable identities and request-time approval logic. Once an agent can reach databases, MCP tools, APIs, and RAG systems, access control has to follow the action, not just the environment.

Key questions

Q: How should security teams govern AI agents that can access enterprise tools and data?

A: Treat the agent as an identity with explicit runtime permissions, not as a harmless extension of the application. Security teams should enforce policy at the point of tool use, data retrieval, and response generation so the agent cannot inherit broader access than the business case allows. That requires coordination between IAM, NHI governance, and application owners.

Q: Why is sandboxing not enough for AI agent security?

A: Sandboxing limits the execution environment, but it does not decide what the agent may access or expose. An agent can still reach databases, APIs, and MCP tools if policy does not intervene during runtime. That is why authorization must sit inside the workflow and evaluate each action against identity and context.

Q: What do security teams get wrong about AI agent access control?

A: They often focus on authentication or output filtering and ignore the permissions attached to the agent’s actions. If the agent can invoke a tool, query a database, or expose data without a live authorization decision, the control model is incomplete. The real risk is inherited reach, not just bad prompts or unsafe models.

Q: How do access reviews change when AI agents are part of the workflow?

A: Access reviews need to cover the agent’s operational permissions, the human context behind the session, and the tools and data the workflow can reach. Reviewing only the user account misses the agent’s effective privilege. Reviews should therefore validate runtime scope, not just static entitlements.

Technical breakdown

Runtime authorization in agentic workflows

Runtime authorization is the practice of making policy decisions during execution rather than only at login or provisioning time. In an agentic workflow, that means the system evaluates the authenticated user, the agent identity, the tool being invoked, and the target data before each action proceeds. This is different from sandboxing, which only constrains the runtime container or environment. The article’s key point is that enterprise AI risk appears when an agent becomes a bridge between identity context and operational capability. Without runtime policy, the agent can inherit reach that was never intended for the use case.

Practical implication: define authorization checkpoints at tool invocation and data retrieval, not just at session start.

MCP tool access as an identity decision

MCP tools are not just technical endpoints. They become authorization surfaces because the agent’s ability to call them determines what it can see, query, and expose. In the article’s demo, one user is blocked from a restricted SQL tool even though the agent and environment exist, which shows that access control must be attached to the action path itself. That is a critical distinction for enterprise security architecture: the tool may be present, but the identity-policy relationship decides whether it is usable in context.

Practical implication: treat each MCP tool as a protected resource with explicit policy, not as a trusted extension of the agent.

Principal context versus agent-only authorization

The article describes two operating modes. Principal context mode ties policy to both the human user and the agent, while agent-only mode manages policy directly for non-user-facing automation. This distinction matters because many AI deployments are neither pure human sessions nor fully autonomous systems. The governance model has to reflect the actual decision chain. If the agent is acting on behalf of a person, the user’s entitlements remain relevant. If the agent is operating as a backend process, the agent itself becomes the governed identity boundary.

Practical implication: classify each agent workflow by whether user context, agent context, or both must drive the policy decision.

Threat narrative

Attacker objective: The objective is to use an apparently legitimate AI session to reach data or actions that should have remained out of scope.

1. Entry occurs when a user or agent is allowed into a sandboxed AI workflow that can still reach enterprise systems through MCP tools, APIs, or databases.
2. Escalation happens when the agent is permitted to invoke a tool or retrieve data that exceeds the user’s intended access scope, even though the runtime is technically isolated.
3. Impact is unauthorized data retrieval or exposure through the agent’s final response, tool invocation, or downstream workflow action.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Runtime authorization is the control layer that AI agents turn from optional to mandatory. Sandboxing reduces infrastructure exposure, but it does not govern what an agent is permitted to query, invoke, or expose once it is inside the environment. The field should stop treating runtime policy as a nice-to-have extension of authentication. Practitioners need to see it as the decision point where agent identity becomes operational authority.

Which user can reach which agent is now a first-order identity question. The article’s HR versus general-user demo shows that AI access is not just about data permissions. It is about whether the user-agent relationship itself is permitted. That makes agent access governance a direct extension of IAM and NHI control design, not a separate AI-only problem. Practitioners should expect agent entitlements to become part of access reviews and lifecycle governance.

Least privilege breaks down when the agent is allowed to inherit broad runtime reach from the hosting workflow. The policy problem is no longer static entitlement assignment alone. It is whether the same identity boundary governs the user, the agent, the tool, and the data path at the moment of action. Practitioners should treat this as an authorization architecture issue, not a prompt-safety issue.

Dynamic authorization is becoming the practical test of whether enterprise AI can be governed at all. The article shows that access can vary by identity, group membership, selected agent, requested tool, and context. That is the governance model the market is moving toward. Security teams should expect policy engines to sit inside agent workflows, because external guardrails alone will not preserve enterprise access boundaries.

Agent-only mode shows that some AI workflows are already functioning as non-human identities. When a backend agent operates without a live human session, it should be governed as an operational identity with explicit policy, scope, and lifecycle rules. The practitioner implication is straightforward: one authorization model will not fit both human-mediated and machine-mediated AI use cases.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• For a broader control lens, see OWASP Agentic Applications Top 10 for the identity and tool-use risks that runtime authorization is designed to constrain.

What this signals

Runtime policy will become the dividing line between governed AI and unmanaged shadow AI. As agentic workflows move from pilots to production, teams will need to decide whether policy lives outside the workflow or inside the decision path. That shift affects IAM architecture, control ownership, and how quickly security teams can contain overreach before it turns into persistent privilege drift. For a deeper control lens, the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework are the right references to anchor the programme.

With 80% of organisations already seeing AI agents act beyond intended scope, per the AI Agents: The New Attack Surface report, the practical signal is clear: static approvals are no longer sufficient for workflows that can decide, call tools, and expose data in real time.

Agent entitlement drift: this is the point at which a managed AI workflow starts accumulating permissions that were never explicitly intended for the task. Teams should watch for tooling sprawl, unclear ownership between IAM and application teams, and missing recertification triggers for agent access paths.

For practitioners

• Define authorization checkpoints at the action layer Place policy decisions at tool invocation, data retrieval, and response exposure so access is evaluated where the agent actually acts.
• Separate human-mediated and agent-only workflows Map which agent flows require user context and which operate as backend identities, then govern each path with the correct policy model.
• Review MCP tools as protected resources Inventory every MCP tool, API, and database connection the agent can reach, then assign explicit access rules to each one.
• Embed runtime policy into IAM reviews Include agent permissions, tool reach, and output exposure in access reviews, recertification, and offboarding processes for AI workflows.

Key takeaways

• AI agent security fails when sandboxing is mistaken for authorization, because the environment can be isolated while the action path remains over-permissioned.
• The article shows that runtime policy must govern users, agents, tools, and data together, or AI workflows will inherit access they were never meant to have.
• For practitioners, the priority is to move agent access into lifecycle governance, with explicit review, scope control, and action-level enforcement.

Key terms

• Runtime Authorization: Runtime authorization is the practice of deciding what an identity can do at the moment an action is attempted. For AI agents, that means checking the user, agent, tool, and data context before allowing retrieval, invocation, or exposure.
• MCP Tool: An MCP tool is an external capability exposed to an AI agent through the Model Context Protocol. In practice, it becomes a governed access surface because the agent’s ability to call it determines what systems, data, and actions are reachable.
• Principal Context: Principal context is an authorization model that evaluates both the human user and the agent acting on the user’s behalf. It matters when access decisions depend on who initiated the session as well as which agent, tool, or resource is being used.
• Agent-Only Mode: Agent-only mode is a governance pattern where the AI agent is authorized directly without a live human session driving each decision. It is used for backend automation and must be treated as a non-human identity with explicit scope and lifecycle controls.

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 responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by PlainID: Securing OpenClaw with runtime authorization. Read the original.