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

5. The Mapping: TBAC's Requirements as Documented Gateway Constructs

Take the four TBAC requirements from Section 3 against TrueFoundry's official documentation. The per-task permission bundle maps to the Virtual MCP Server: per the authentication and security docs, "you can also create a Virtual MCP Server, allowing you to expose a subset of tools from different MCP servers" — precisely a curated, minimal tool bundle assembled for a class of work rather than an identity's full entitlement. The identity boundary maps to the documented layering: "any user/application requires a token to talk to the gateway — so that the gateway can identify the user and subsequently impose authorization rules," with gateway-layer access control defining "which users have access to which MCP servers" (same docs). Inbound identity, access decision, and outbound credential are independent planes — the credential that reaches the gateway is never the one that reaches the downstream tool.

Duration binding and delegation map to the credential model. The Agent Harness documentation states no API keys or credentials are ever pasted into agent definitions — agents reference MCP servers by name while "the gateway handles credential injection, token refresh, and user delegation," and with per-user OAuth "every user will have their own token" and the server grants only what that user may access (docs). Delegation captured structurally: the agent acts with the authorizing user's scoped token, not a god-mode service key. Transactional checkpoints map to human-in-the-loop approval gates, which pause sensitive tool calls for explicit approval. And the per-agent boundary is documented at the Agent Gateway: token- or cost-based quotas "per agent, workflow, or environment," RBAC over who may deploy, execute, or modify agents, and — TBAC's audit anchor — all agent actions, model calls and tool invocations alike, logged and auditable.

The layered BACs as gateway configuration — one agent, four questions (illustrative)

---
# Defining an MCP Server
mcp_server:
  name: order-tools
  collaborators: 
    - "team:support-eng"              # RBAC — outer boundary, org-chart-shaped
  auth: oauth2_authorization_code     # delegation — per-user token, gateway-managed refresh

---
# Defining a Virtual MCP Server
virtual_mcp_server:
  name: refund-task-bundle            # TBAC — the per-task tool bundle
  tools:
    - "order-tools/lookup_order"      # minimal set: two tools, not the server's twenty
    - "order-tools/issue_refund"

---
# Defining an Agent
agent:
  name: support-refund-agent
  identity: "virtualaccount:refund-agent" # its own principal, not a borrowed human session
  mcp_servers: 
    - refund-task-bundle                  # sees only the task bundle
  quotas: 
    cost_per_day: "50_usd"                # ABAC-flavored: metadata-filtered, per-agent
  approvals:
    issue_refund: human                   # transactional checkpoint on the irreversible

# Every invocation: inbound auth → RBAC check → policy/guardrails → scoped outbound
# credential → audit log. Constructs per truefoundry.com/docs; schema simplified.

6. Compliance: Why the Layering Is Auditable, Not Just Safe

Access control earns its keep twice — preventing incidents and proving governance — and the second is where regulated enterprises live. The layered model has a compliance story because each layer leaves a record at one control point: every request logged with token-level usage attribution, all agent-initiated tool actions audited, and RBAC changes applied centrally across all clients without redeployment. TrueFoundry's published compliance posture backs the infrastructure itself: SOC 2 Type 2 and HIPAA compliance, with deployment as SaaS, self-hosted, on-prem, or air-gapped so the enforcement point sits inside the customer's boundary when regulation requires — per the AI Gateway product documentation, data-handling policies like PII masking operate wherever the gateway runs, and "no data leaves your domain."

This matters for TBAC specifically because the model's hardest audit question — why did the agent make this call, and was it within its authorized task? — is answerable only if task context, identity, policy decision, and action land in one trace. The practitioner literature calls this the causal-chain gap: teams log the API call but lose the authorization story around it. A gateway that authenticates the caller, checks RBAC, applies metadata policy, injects the scoped credential, and writes the audit record in a single pass closes it. Worth saying plainly rather than superlatively: this is the layered, agent-aware access model the moment requires, implemented at enterprise grade. Whether it is "the most modern" is a marketing question; that it is documented, shipping, and auditable is a verifiable one.

7. Honest Limits: What TBAC Is Not (Yet)

Three boundaries keep this credible. First, no platform ships TBAC as a checkbox, TrueFoundry included — what exists are the enforceable primitives the model requires: scoped bundles, per-agent identity, delegated credentials, approvals, audit. Assembling them into per-task authorization is design work the platform enables, not a toggle. Second, task inference is genuinely hard. TBAC's cleanest form assumes the system knows what task is executing; agents blur that, and the LLM-as-judge frontier is promising but early, with open problems its authors acknowledge around uncertainty and manipulation — a judge that can be prompt-injected is a guard that can be talked past. Third, the older models are load-bearing: RBAC stays as the outer boundary and ABAC as runtime context; ripping out roles to chase task-based purity trades an auditable coarse control for an unproven fine one. TBAC is the newest layer of a stack, not a successor ideology.

8. Where This Lands: Ines's Third Option

Ines's review closed with the third option she wanted, built from documented parts. The support agent got its own identity — a virtual account, not a borrowed human session — with RBAC granting exactly one thing: a Virtual MCP Server exposing lookup and refund, two tools curated from a twenty-tool server. Its calls run on per-user OAuth delegation, so it touches only what the ticket's customer context entitles; its spend is quota-bounded; and the one irreversible action, the refund, pauses for human approval above a threshold. Every invocation lands in an audit log tying identity, policy decision, and action together — the causal chain her incident-response process needs. No standing god-mode role, no broken agent: permissions assemble around the work, bounded in scope, duration, and blast radius. The 1990s idea, running on 2026 infrastructure.

That is the honest arc of TBAC. "Who are you?" served access control for forty years because principals were people. Agents made "what are you doing right now?" the binding question, and the answer is not a new acronym replacing the old ones — it is the old ones layered correctly, task-scoped constructs on top, enforced at the one point every model and tool call already passes through. The gateway was built to be that point. The agent age is what finally made the 1990s right.

9. Frequently Asked Questions

Is TBAC a standard like RBAC? No. RBAC has formal standardization; TBAC is a research lineage — Thomas and Sandhu's 1990s work — now revived in agent-security research and industry writing (Cisco Outshift's framing, the LLM-judged TBAC model on arXiv). Treat it as a design pattern with a strong pedigree, not a certifiable spec. Its value is the question it forces: is this action serving the authorized task, within its bounds?

Should we replace RBAC with TBAC for our agents? No — and no serious source recommends it. RBAC remains the auditable outer boundary; attribute policies handle runtime context; TBAC-shaped constructs bound the work. The practical move is additive: agent identities, per-task tool bundles, delegated per-user credentials, gates on the irreversible, audit at one point.

How does this apply to RAG, not just tools? Retrieval is access control too: documents carry entitlements, and the querying user's permissions — not the pipeline's service account — should bound what retrieval returns. That is ABAC/ReBAC territory at the data layer, complemented at the gateway by per-user delegation (an agent's queries carry the user's scoped identity downstream) and guardrails like PII masking in the response path.

What's the single highest-leverage first step? Give every agent its own identity with no embedded credentials. Quotas, RBAC, delegation, and audit all attach to identity — and it is the documented default on a governed runtime: per TrueFoundry's Agent Harness docs, agents reference models and tools by name while credentials live centrally in the gateways. An agent you can't individually identify is one you can't individually govern.

Can an LLM judge whether an action serves the task? That is the live research question. The arXiv TBAC work uses an uncertainty-aware LLM judge and is candid about open problems; the conservative production posture is deterministic bounds — bundles, quotas, approvals, short-lived scopes — with LLM judgment as an additional signal, never the sole gate on an irreversible action.

References

• Thomas, R.K. and Sandhu, R.S. — task-based authorization controls (TBAC), the 1990s foundation: permissions bundled into tasks, minimal privileges for an activity's duration. Paraphrased with credit. https://profsandhu.com/confrnc/ifip/i97tbac.pdf
• "Uncertainty-Aware, Risk-Adaptive Access Control for Agentic Systems using an LLM-Judged TBAC Model" (arXiv:2510.11414, 2025) — the modern research revival, building on TBAC for its "natural alignment with the goal-oriented nature of AI agents." https://arxiv.org/abs/2510.11414
• Cisco Outshift — "Tool, transaction, task-based access control (TBAC): Securing agentic AI beyond RBAC, ABAC, and ReBAC"; plus practitioner analyses from Oso ("Why RBAC Is Not Enough for AI Agents"), Kiteworks (ABAC vs. RBAC for agents), and tianpan.co (task-scoped credentials, request-context binding) — all paraphrased with credit.
• IBM Cost of a Data Breach research (2025) and SpyCloud Identity Exposure Report (2026), as relayed in agent-security industry reporting — the empirical gap: AI incidents correlated with missing AI access controls, and large-scale exposure of AI-tool credentials. Cited here via secondary industry analyses; consult the primary reports for exact figures.
• TrueFoundry MCP Gateway Authentication & Security docs — inbound auth, gateway-layer access control, Virtual MCP Servers, per-user OAuth; Agent Harness docs — no credentials in agent definitions, credential injection, delegation, approvals.
• TrueFoundry Agent Gateway and AI Gateway — per-agent quotas, agent-level RBAC, audit logging, metadata-filtered policies, guardrails, and deployment/compliance posture (SOC 2 Type 2, HIPAA; SaaS/self-hosted/on-prem/air-gapped).

Ines is an illustrative composite, not a specific person, organization, or review. The access-control history and agent-era analyses are paraphrased with credit from the cited standards, papers, and industry writing; quoted fragments are under fifteen words and attributed. Third-party statistics (IBM, SpyCloud) are reported figures from the cited research as relayed in industry analyses. TBAC is a design pattern and research lineage, not a certified standard, and no platform ships it as a single feature; TrueFoundry capabilities are quoted from public documentation and product pages at the time of writing — verify against current docs at truefoundry.com/docs. The configuration snippet is simplified for readability and is not literal product schema.

‍

‍