Why AI Agent Sandboxing Is Not Enough: Securing OpenClaw With Runtime Authorization

Authorization becomes the critical control layer the moment AI agents start interacting with enterprise systems, MCP tools, APIs, databases, and sensitive business data. OpenClaw gives organizations a fast way to deploy AI agents, but once those agents move beyond isolated testing environments, enterprises need real-time authorization decisions that control what users and agents can access, retrieve, invoke, and expose.

A sandbox can reduce infrastructure risk by isolating the runtime environment. But sandboxing alone does not solve the larger authorization problem inside enterprise AI systems. Organizations still need to control which agents users can access, which MCP tools an agent can invoke, which data can be retrieved, and whether sensitive information should be exposed in the final response.

At PlainID, we see this challenge becoming more urgent as enterprises move from experimental AI projects to production AI workflows connected to real business systems.

In this demo, Motti Gabai, Product Manager at PlainID, shows how the new PlainID OpenClaw plugin adds runtime authorization directly into the agentic workflow. Instead of wrapping OpenClaw in a separate platform, the plugin integrates directly into the existing OpenClaw environment and applies real-time authorization decisions across users, agents, and tools.

The Problem With AI Agent Sandboxing

Many organizations are adopting sandboxed AI environments as an initial security layer. NVIDIA’s enterprise approach for OpenClaw is one example. The idea is straightforward: isolate the AI agent inside a containerized environment so that if something goes wrong, the impact stays limited.

That helps with infrastructure isolation.
But enterprise AI agents rarely stay isolated for long.
To become useful, agents need access to:

• Internal databases
• MCP tools
• APIs
• RAG systems
• SaaS applications
• Sensitive enterprise data
• Business workflows

Once an AI agent starts interacting with real systems, the main question changes from:
“Can the agent run safely?” to: “What exactly is this agent allowed to do?”

This is where runtime authorization becomes critical.
Authentication alone is not enough. Even if a user is authenticated, the organization still needs to control:

• Which agent they can access
• Which tools that agent can invoke
• Which data can be retrieved
• Which responses can be exposed
• Whether access should change based on user identity or business context

Without those controls, a general-purpose AI assistant can easily become a path to unauthorized data
exposure.

How the PlainID OpenClaw Plugin Works

The PlainID OpenClaw plugin adds runtime authorization directly into the OpenClaw flow.

Instead of creating a separate wrapper around OpenClaw, the plugin works with an existing OpenClaw deployment and integrates authorization decisions into the runtime process itself.

In the demo environment, the setup includes:

• OpenClaw
• NGINX as a trusted proxy
• Keycloak for authentication
• PlainID for runtime authorization

When a user logs into OpenClaw through Keycloak, PlainID creates a runtime relationship between:

• The authenticated user
• The AI agent
• The tools and resources the agent wants to access

This allows authorization decisions to happen dynamically during the interaction itself.
The result is identity-aware authorization across the entire AI workflow.

The Demo Setup

To demonstrate the flow, the environment includes two user groups:

• HR team members
• General organization employees

The demo also includes two AI agents:

Agent	Who Can Access It	Available Capabilities
General Assistant Agent	All employees	General AI assistant capabilities
HR Agent	HR team only	Access to SQL MCP tools and employee data

The HR agent is connected to a local SQL MCP server that exposes two database tools:

• List tables
• Read query

PlainID policies define which users and agents can access those tools.

Runtime Authorization in Action

The first test uses Alice, a general employee who is not part of the HR team.

Attempt 1: Accessing the HR Agent

Alice tries to interact with the HR agent.
PlainID immediately blocks the request.
The system returns an unauthorized message because Alice does not have permission to access that agent.
This is an important distinction.
The restriction is not only tied to the data source. The authorization decision happens earlier in the flow at the agent level itself.

Attempt 2: Using a General Agent to Reach Restricted Data

Next, Alice accesses the general assistant agent, which she is allowed to use.
The agent responds normally.
But then Alice attempts to use a database-related MCP tool to list available SQL tables.
This time, PlainID blocks the tool invocation itself.

Even though:

• Alice is authenticated
• The assistant agent is accessible
• The MCP tool technically exists in the environment

The runtime authorization policy prevents the agent from invoking the restricted SQL tools because Alice does not have the required permissions.

This is where many AI security models fail.

Traditional AI guardrails often focus on prompts or output filtering. But they do not always control runtime tool execution using enterprise identity and policy context.

PlainID applies authorization decisions directly at the point of action.

What Happens When an Authorized HR User Logs In

The second test uses a user who belongs to the HR team.
This time, the user successfully accesses the HR agent.
When the user asks for employee data, the HR agent invokes the allowed SQL MCP tools:

• List tables
• Read query

The agent successfully retrieves employee information because the runtime authorization policies allow it.
The important detail is that access is not hardcoded into the agent.
The same OpenClaw environment behaves differently depending on:

• The authenticated user
• Group membership
• The selected AI agent
• The requested tool
• The runtime policy decision

This creates dynamic authorization enforcement across the AI workflow.

Why This Matters for Enterprise AI Security

As AI agents become more connected to enterprise systems, organizations need more than authentication and sandboxing.
They need runtime authorization.
This includes controlling:

Authorization Question	Why It Matters
Which users can access which agents?	Prevents unauthorized agent usage
Which tools an agent can invoke?	Stops unauthorized MCP or API access
Which data can be retrieved?	Protects sensitive enterprise information
Which outputs can be exposed?	Reduces accidental data leakage
How policies change by context?	Supports least privilege and dynamic access control

Without runtime authorization, organizations risk creating AI agents that unintentionally bypass existing access controls.

An AI assistant should not automatically inherit unrestricted access to every connected tool or data source.

Authorization decisions still need to happen in real time.

Two Deployment Modes for the Plugin

The PlainID OpenClaw plugin supports two deployment approaches.

Principal Context Mode

This is the mode demonstrated in the video.
Authorization decisions are based on both:

• The user identity
• The AI agent identity

This allows enterprises to enforce identity-aware authorization policies across the full interaction flow.

Agent-Only Mode

The plugin also supports a lighter deployment model without user authentication.
In this mode, organizations can manage authorization policies directly for AI agents themselves.

This is useful for:

• Internal automation agents
• Background AI workflows
• System-to-system agent interactions
• Non-user-facing AI processes

Runtime Authorization Becomes the Real Control Layer

AI agents are becoming operational actors inside enterprise systems.

They retrieve data.
They invoke tools.
They call APIs.
They make decisions.
They generate responses.

That means enterprises need a way to control those actions consistently and dynamically.
Sandboxing helps contain infrastructure risk.
Runtime authorization controls operational risk.
At PlainID, we believe authorization is where trust is created or broken.

The OpenClaw plugin demonstrates how organizations can apply centralized, identity-aware, runtime authorization across AI agents, MCP tools, and enterprise resources without rebuilding their existing AI environments.

Want to See the Demo?

The PlainID OpenClaw plugin is available as a community plugin in the OpenClaw repository.

To learn more about how PlainID helps organizations secure AI agents, MCP workflows, APIs, applications, and sensitive data with runtime authorization, visit the PlainID Agentic AI security or book a demo

FAQ