Notifications
Clear all
Topic starter
24/06/2026 7:13 pm
TL;DR: AI agents chain tools, delegate to sub-agents, and keep acting after the first prompt, so authorization must answer who is acting, for whom, on what resource, through which tool, right now, according to PermitIO. RBAC sets boundaries, but ReBAC plus runtime conditions is the only model that can reliably govern delegated agent actions at execution time.
NHIMG editorial — based on content published by PermitIO: RBAC vs ReBAC for AI Agents: Best Authorization Model for Secure Agentic Systems
Questions worth separating out
Q: How should security teams authorize AI agents that act on behalf of humans?
A: Use RBAC for broad boundaries, ReBAC for delegated and resource-aware decisions, and runtime conditions for risk-sensitive actions.
Q: Why do RBAC policies often fail for AI agent governance?
A: RBAC fails when the real decision depends on delegation, tenant scope, sub-agent propagation, or changing runtime conditions.
Q: What breaks when delegated context is missing from agent authorization?
A: Without delegated context, an agent may appear authorised even when it is acting outside the human’s intent, outside the tenant boundary, or beyond an allowed business limit.
Practitioner guidance
- Model delegated agent identity explicitly Represent the human delegator, parent agent, child agent, resource, and tenant as separate policy inputs so authorization can evaluate the real execution chain instead of a generic token.
- Enforce every tool invocation through a policy engine Route MCP and API actions through a centralized enforcement point so the decision is checked at runtime, not assumed from prior login or pre-approved scope.
- Apply condition checks to high-risk agent actions Add runtime controls for amount, time, environment, and risk so the same agent can be allowed for low-risk tasks but denied when the business context changes.
What's in the full article
PermitIO's full article covers the operational detail this post intentionally leaves for the source:
- Policy examples that show how RBAC and ReBAC differ in actual agent workflows
- A practical decision table for delegation, sub-agent propagation, and tenant isolation
- Implementation patterns for enforcing tool calls through a PDP or gateway layer
- Audit and logging considerations for per-decision explainability and incident response
👉 Read PermitIO's analysis of RBAC vs ReBAC for AI agent authorization →
RBAC vs ReBAC for AI agents: is your runtime control model enough?
Explore further
25/06/2026 4:25 am
RBAC is the boundary layer, not the decision layer, for AI agents. In agentic systems, a role can say what a class of agent may attempt, but it cannot capture the full delegated context of who asked, what resource is targeted, and whether the action is still in scope at execution time. That makes RBAC necessary but structurally incomplete for production agent governance. Practitioners should treat RBAC as the outer guardrail, not the final authoriser.
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 complete blind spot for compliance and breach investigation, according to SailPoint research.
A question worth separating out:
Q: Who is accountable when an AI agent makes an unauthorised action?
A: Accountability sits with the organisation that defined the delegation model, enforced the policy, and approved the agent workflow. If the policy layer cannot explain who delegated authority, what resource was touched, and why the action was allowed, accountability is already incomplete.
👉 Read our full editorial: RBAC vs ReBAC for AI agents: where runtime authorization breaks
