Topic starter
20/08/2026 5:52 pm
TL;DR: AI agents break identity-centric access control because their permissions need to change by task, not by stable principal, TruFoundry argues, and revives task-based access control as the better fit for agentic workloads. The practical shift is from standing entitlements to layered, task-scoped governance, because access review assumes access persists long enough to review.
Editorial analysis by NHI Mgmt Group, based on content published by TruFoundry: “TBAC: Task-Based Access Control for the Agent Age”.
Key questions
Q: What breaks when AI agent access is managed like standard IAM access?
A: What breaks is the assumption that access is stable, reviewable, and tied to a single human owner.
Q: Why do AI coding agents increase the need for task-scoped access controls?
A: AI coding agents can move across code, tests, and connected systems faster than a human developer, which makes standing access more dangerous.
Q: How should teams decide whether an agent needs standing access or task-scoped access?
A: Use standing access only when the action set is truly stable, low risk, and repeated under the same conditions.
Practitioner guidance
- Define task-scoped permission bundles Map the minimum tools, data objects, and actions each agent task genuinely needs, then bind those permissions to the task instance rather than the agent identity alone.
- Separate outer boundary and task boundary Keep RBAC as the auditable outer gate, then use attribute policy and task scoping to decide what the agent may do inside that boundary.
- Require runtime delegation records Log the originating user, the task being executed, and the downstream tool call so each action can be traced back to a specific authorisation decision.
Bottom line: AI agents expose the weakness in access models that assume a stable principal and a stable permission set.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:31 pm
TBAC is a governance response to agentic work, not a cosmetic rename of RBAC. The article is right to treat task scope as the missing unit of authorisation for agents, because stable principal models do not describe how agent work actually unfolds. That makes TBAC most useful as a governance lens: it forces teams to define the work first, then decide what the agent may touch. The practitioner takeaway is that agent access design should start from task boundaries, not from inherited identity patterns.
A few things that frame the scale:
- 62% of organisations are at least experimenting with AI agents, but only 23% have scaled one into a single business function, according to McKinsey's 2025 State of AI survey.
A question worth separating out:
Q: What should security teams audit in agent authorisation records?
A: Audit the originating request, the task description, the permissions granted for that task, and the downstream actions taken. If those elements are not tied together, you cannot prove whether the agent acted within scope. The goal is to show that the access decision matched the work being done.
👉 Read our full editorial: TBAC for AI agents: why task-scoped access is emerging now