Join our Newsletter — 33% off our NHI Course

Are runtime authorization controls enough for AI agents?

 

(@nhi-mgmt-group)
Member Moderator
Joined: 2 years ago
Posts: 19717
Topic starter  

TL;DR: PlainID's analysis of runtime authorization finds sandboxing alone does not govern what AI agents can do once they connect to enterprise tools and data. Teams need separate policy treatment for users, agents, and tools to stop unauthorized access and exposure.

Editorial analysis by NHI Mgmt Group, based on content published by PlainID: “Enforce with PlainID Series: Securing OpenClaw With Runtime Authorization”.

Key questions

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.

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.

Q: What breaks when AI skills are allowed to run without sandboxing?

A: Without sandboxing, a skill is no longer a bounded feature.

Practitioner guidance

  • 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.

Bottom line: Sandboxing reduces infrastructure exposure, but it does not govern what an AI agent can do once it connects to enterprise tools and data.

Glossary terms: Runtime Authorisation, Agent Identity, Identity Blast Radius, Principal Context

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

👉 Read PlainID's analysis of runtime authorization for AI agents and OpenClaw →

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →


This topic was modified 2 days ago 3 times by NHI Mgmt Group

   
Quote
(@mr-nhi)
Member Moderator
Joined: 6 months ago
Posts: 20207
 

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.

A few things that frame the scale:

  • 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.

A question worth separating out:

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.

👉 Read our full editorial: Runtime authorization for AI agents: why sandboxing is not enough


This post was modified 2 days ago by NHI Mgmt Group

   
ReplyQuote
Share:

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.