Notifications
Clear all
Topic starter
24/06/2026 7:05 pm
TL;DR: Sandboxing alone does not solve enterprise AI risk: once agents connect to MCP tools, APIs, databases, and business workflows, runtime authorization must decide what users and agents can access, retrieve, invoke, and expose, according to PlainID. The control problem is no longer containment but assumption collapse around who or what is allowed to act.
NHIMG editorial — based on content published by PlainID: Securing OpenClaw with runtime authorization
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
PlainID's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step demo flow showing how runtime authorization blocks restricted SQL MCP tool usage in OpenClaw
- The exact role split between Keycloak authentication, NGINX proxying, and PlainID policy enforcement in the runtime path
- The two deployment modes, principal context and agent-only, that determine how policy is applied to different AI workflows
- Practical examples of how the same OpenClaw environment behaves differently for HR and non-HR users
👉 Read PlainID's analysis of runtime authorization for OpenClaw agent security →
AI agent runtime authorization: are your controls keeping up?
Explore further
25/06/2026 4:13 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Runtime authorization for AI agents: why sandboxing is not enough
