TBAC: Task-Based Access Control for the Agent Age

Most access-control models in production still start from a stable principal: who is asking, what attributes or relationships attach to them, and what that entitles them to. Roles answered it for the org chart, attributes for context, relationships for social graphs. AI agents break the question itself — an agent's identity is stable but its work is not: deployed per task, needing a different permission slice for every task, running at machine velocity, following instructions embedded in the data it reads. The model the moment demands asks: what work are you doing right now? That question has a name with a long pedigree — task-based access control, TBAC, proposed by Thomas and Sandhu in the 1990s and now revived in adapted form for agentic AI. This post reviews the access-control family honestly, explains why agents strain each model, introduces TBAC and its modern formulations, and maps the layered result onto the gateway constructs that implement it, grounding the TrueFoundry mapping in public documentation.

Ines, a security architect, got the review request every security team is getting this year: approve a support agent that reads tickets, queries the order database, and issues refunds under fifty dollars. Her instinct was twenty years of practice: create a role. But support-agent as a role felt wrong by lunch. A role is provisioned once and describes a stable job; this agent needed the refund permission only during refund tasks, the database only for the ticket's customer, and nothing between runs. Worse, it would hold whatever she granted continuously, across every parallel instance, at machine speed — and if a malicious ticket told it to do something creative with its permissions, it might comply. The role model gave her two bad options: over-grant and accept standing exposure, or under-grant and break the agent. She wanted a third thing: permissions assembled per task, scoped to the task's objects, alive for its duration, gone when it ended. That third thing has existed, on paper, since before she started her career.

1. A Short, Honest History of the BACs

Each generation of access control encodes an assumption about the principal. The earliest split — discretionary control (DAC), where resource owners grant access, versus mandatory control (MAC), where a central authority labels and clears — assumed people with clearances. RBAC, formalized by Ferraiolo, Kuhn, and Sandhu in the 1990s and later standardized, bound permissions to roles rather than individuals: a developer role gets repositories, a clinician role gets patient records. Its deep assumption: principals have stable job functions changing on an organizational timescale — true for employees, and why RBAC still runs most enterprises.

ABAC — attribute-based access control, canonically treated in NIST SP 800-162 — replaced role lookup with policy evaluation over attributes of subject, resource, action, and environment: allow if department = finance and classification ≤ internal and business hours. It buys flexibility at the cost of policy-authoring complexity, and as agent-security analyses note, it evaluates context well but does not inherently understand the intent behind a request. ReBAC — relationship-based access control, popularized by Google's Zanzibar paper — derives permissions from graph relationships: you can edit this document because you own its parent folder. Alongside these sit PBAC as an umbrella for policy-engine approaches and just-in-time access from privileged-access management — a preview, from the human world, of duration-bound permission. Every one of these models answers "who are you, and what does that entitle you to?" — provisioned before the work begins. That is precisely the assumption agents violate.

2. Why Agents Break Identity-Centric Access Control

The strain is structural, and the agent-security literature has converged on a consistent diagnosis. First, agents have no stable job function: they are deployed for specific tasks, operate across variable data scopes, execute at machine velocity, and run parallel instances — a "clinical documentation agent" role granting PHI-repository access cannot express that this instance is authorized for these three records for this encounter, as one ABAC-versus-RBAC analysis puts it. Second, agents can exercise what they hold, programmatically and at scale — Oso's framing is the sharpest: employees ignore the vast majority of their permissions; agents won't. Over-provisioning that is untidy for humans becomes an active attack surface for a principal that can explore its permission space at machine speed. Third, agents can be talked into things: prompt injection means instructions arrive through the data an agent reads, so a standing permission is a standing target — the confused-deputy problem with a language interface.

Fourth, and least appreciated: delegation chains blur accountability. On-behalf-of flows silently escalate — the agent inherits the user's full session scope, including permissions irrelevant to the task — and multi-agent handoffs pass authority without re-evaluation. Practitioner guidance converges on request-context binding: every downstream call carries the originating user, the task, and the authorization decision, because the privilege boundary must move from login time to request time. The cost of not doing this shows up in the breach literature: industry reporting citing IBM's 2025 Cost of a Data Breach research indicates the overwhelming majority of organizations with AI-related security incidents lacked proper AI access controls, and SpyCloud's 2026 identity-exposure reporting points to large-scale exposure of API keys and tokens, including credentials tied to AI tools. The models built for people are, by these accounts, not holding for agents.

3. Enter TBAC: an Old Idea Whose Principal Finally Arrived

Task-based access control is not new — which is what makes its revival credible. In the 1990s, Roger Thomas and Ravi Sandhu proposed task-based authorization controls as a shift from subject-centric to activity-centric authorization: permissions bundled into tasks, granted as the minimal set a specific activity requires, active for its duration, consumed or revoked as the workflow progresses. The idea was ahead of its infrastructure — 1990s workflow systems didn't need it badly enough. Agents do. A recent arXiv paper on risk-adaptive access control for agentic systems builds on TBAC "due to this natural alignment with the goal-oriented nature of AI agents" — an agent, unlike an employee, genuinely is its current task.

The modern formulations extend the original in two directions. Cisco Outshift's framing — tool, transaction, task-based access control — positions TBAC explicitly as the layer beyond RBAC, ABAC, and ReBAC for agentic AI: authorization scoped not to who the agent is but to the tools it may call, the transactions it may complete, and the task it is executing. The research frontier probes how the "task" gets adjudicated at all: the arXiv work uses an LLM as an uncertainty-aware judge of whether an action serves the authorized task — promising, early, honest about its open problems. Between practitioner consensus and research, a working definition emerges. Agent-era TBAC means: a per-task permission bundle (minimal tools and data for this objective), duration binding (short-lived, task-scoped credentials with TTLs in minutes), delegation capture (the task carries who authorized it, on whose behalf), and transactional checkpoints (irreversible steps get an explicit gate). None of that replaces the older models — it sits on top of them, which is the design insight the next sections make concrete.

4. The Layered Model: Where Each BAC Still Earns Its Place

The practitioner literature is unanimous on one point: replacing RBAC entirely is neither necessary nor advisable. The models compose, and in an LLM/RAG/MCP stack each has a station. RBAC remains the outer boundary — which teams and services may reach which models, MCP servers, and agents at all; coarse, auditable, org-chart-shaped, exactly what an outer boundary should be. ABAC-style policy runs at request time — team, environment, data classification, and cost metadata deciding whether this call, in this context, proceeds; in RAG this is where document-level permissions live, so retrieval respects the querying user's entitlements rather than the pipeline's. ReBAC governs the data's own structure — ownership and inheritance — mattering most where agents traverse content graphs like drives and wikis. TBAC binds the work: the per-task tool bundle, the task-scoped credential, the delegation record, the checkpoint on irreversible actions.

Read as a stack, the models answer four questions about one agent request: is this principal allowed here at all (RBAC), is this request acceptable in context (ABAC), does the data's structure permit it (ReBAC), does this action serve the authorized task within its bounds (TBAC). Enforce all four at one control point, with one audit record tying them together, and you have what the agent age requires. That point is the gateway — and here the argument stops being conceptual, because these constructs exist as documented, shipping features.

‍

‍