Notifications
Clear all
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.
NHIMG editorial — based on content published by TruFoundry: TBAC: Task-Based Access Control for the Agent Age
By the numbers:
- While 71% of IT teams have been advised on AI agent data access, only 47% of compliance teams, 39% of legal teams, and 34% of executives have the same visibility.
Questions worth separating out
Q: How should security teams manage permissions for AI agents?
A: Security teams should regularly assess and update the permissions granted to AI agents to ensure they align with their intended scope.
Q: Why do AI agents complicate traditional IAM and PAM controls?
A: AI agents complicate IAM and PAM because they can make decisions, chain tools, and act faster than human review cycles can respond.
Q: What do teams get wrong when they give agents broad tool access?
A: They treat the agent like a normal service account and over-grant to avoid workflow breakage.
Practitioner guidance
- Map agent work into explicit task objects Define the task start, task end, allowed tools, and irreversible actions for every agent workflow.
- Separate outer-boundary identity from task-scoped access Use RBAC or IdP policy to control who may deploy or approve the agent, then use task-scoped permissions to control what the agent can do during execution.
- Remove standing credentials from agent definitions Keep API keys and downstream tokens out of agent prompts or configuration files.
What's in the full article
TruFoundry's full article covers the implementation detail this post intentionally leaves at the governance layer:
- A layered mapping of RBAC, ABAC, ReBAC, and TBAC to gateway enforcement points for agent workflows.
- Documentation-based examples of curated tool subsets, per-agent quotas, and human approval gates.
- Operational notes on credential injection, token refresh, and audit logging for every tool call.
- The platform-specific boundary conditions around when task inference remains research rather than production policy.
👉 Read TruFoundry's analysis of TBAC for AI agents and gateway governance →
TBAC for AI agents: is task-scoped access the right model?
Explore further
20/08/2026 6:31 pm
TBAC is not a replacement for IAM, it is the missing task boundary for agentic work. RBAC, ABAC, and ReBAC still matter, but they answer different questions: who may act, under what conditions, and across what relationships. TBAC answers what the agent is authorised to do in this specific work unit, which is the control plane that agentic systems actually need. The implication is that identity governance must treat task scope as a first-class object, not a side effect of role assignment.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
A question worth separating out:
Q: How do you know if task-based access control is working for AI agents?
A: Look for three signals: each task has a defined permission bundle, every downstream call is tied to that task, and sensitive actions cannot complete without approval or full audit evidence. If the agent still carries broad standing credentials, TBAC is only aspirational.
👉 Read our full editorial: TBAC for AI agents: why task-scoped access is emerging now
