TBAC: Controle de Acesso Baseado em Tarefas para a Era dos Agentes

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. Limites honestos: O que o TBAC não é (ainda)

Três limites mantêm isso credível. Primeiro, nenhuma plataforma oferece o TBAC como uma simples caixa de seleção, incluindo a TrueFoundry — o que existe são as primitivas aplicáveis que o modelo exige: pacotes de escopo, identidade por agente, credenciais delegadas, aprovações e auditoria. Montá-las em uma autorização por tarefa é um trabalho de design que a plataforma possibilita, não um botão de ligar/desligar. Segundo, a inferência de tarefas é genuinamente difícil. A forma mais limpa do TBAC pressupõe que o sistema saiba qual tarefa está sendo executada; os agentes tornam isso confuso, e a fronteira do "LLM como juiz" é promissora, porém inicial, com problemas em aberto que seus próprios autores reconhecem em relação à incerteza e manipulação — um juiz que pode sofrer injeção de prompt é um guarda que pode ser convencido a abrir a porta. Terceiro, os modelos mais antigos são fundamentais: o RBAC permanece como o limite externo e o ABAC como contexto de tempo de execução; remover funções para buscar uma pureza baseada em tarefas troca um controle amplo e auditável por um refinado e não comprovado. O TBAC é a camada mais recente de uma pilha, não uma ideologia sucessora.

8. Onde isso chega: A terceira opção de Ines

A análise de Ines terminou com a terceira opção que ela desejava, construída a partir de partes documentadas. O agente de suporte recebeu sua própria identidade — uma conta virtual, não uma sessão humana emprestada — com o RBAC concedendo exatamente uma coisa: um servidor MCP virtual que expõe consulta e reembolso, duas ferramentas selecionadas de um servidor de vinte ferramentas. Suas chamadas são executadas com delegação OAuth por usuário, portanto, ele acessa apenas o que o contexto do cliente no ticket permite; seus gastos são limitados por cotas; e a única ação irreversível, o reembolso, pausa para aprovação humana acima de um limite. Cada invocação cai em um log de auditoria que vincula identidade, decisão de política e ação — a cadeia causal que seu processo de resposta a incidentes precisa. Sem função de "modo deus" permanente, sem agente quebrado: as permissões se reúnem em torno do trabalho, limitadas em escopo, duração e raio de explosão. A ideia dos anos 1990, rodando em infraestrutura de 2026.

Esse é o arco honesto do TBAC. "Quem é você?" serviu ao controle de acesso por quarenta anos porque os principais eram pessoas. Os agentes tornaram "o que você está fazendo agora?" a pergunta obrigatória, e a resposta não é uma nova sigla substituindo as antigas — são as antigas dispostas corretamente em camadas, com construções de escopo de tarefa no topo, aplicadas no único ponto pelo qual toda chamada de modelo e ferramenta já passa. O gateway foi construído para ser esse ponto. A era dos agentes é o que finalmente fez os anos 1990 estarem certos.

9. Perguntas frequentes

O TBAC é um padrão como o RBAC? Não. O RBAC possui padronização formal; o TBAC é uma linhagem de pesquisa — o trabalho de Thomas e Sandhu nos anos 1990 — agora revivida na pesquisa de segurança de agentes e em publicações do setor (a estrutura da Cisco Outshift, o modelo TBAC julgado por LLM no arXiv). Trate-o como um padrão de design com um pedigree forte, não como uma especificação certificável. Seu valor é a pergunta que ele força: esta ação está servindo à tarefa autorizada, dentro de seus limites?

Devemos substituir o RBAC pelo TBAC para nossos agentes? Não — e nenhuma fonte séria recomenda isso. O RBAC permanece como o limite externo auditável; políticas de atributos lidam com o contexto de tempo de execução; construções moldadas pelo TBAC limitam o trabalho. O movimento prático é aditivo: identidades de agente, pacotes de ferramentas por tarefa, credenciais delegadas por usuário, portões para o que é irreversível e auditoria em um único ponto.

Como isso se aplica ao RAG, e não apenas a ferramentas? A recuperação também é controle de acesso: documentos carregam direitos, e as permissões do usuário que faz a consulta — não a conta de serviço do pipeline — devem limitar o que a recuperação retorna. Esse é o território do ABAC/ReBAC na camada de dados, complementado no gateway pela delegação por usuário (as consultas de um agente carregam a identidade com escopo do usuário a jusante) e guardrails como mascaramento de PII no caminho de resposta.

Qual é o primeiro passo de maior impacto? Dê a cada agente sua própria identidade, sem credenciais incorporadas. Cotas, RBAC, delegação e auditoria estão todos vinculados à identidade — e esse é o padrão documentado em um runtime governado: conforme a documentação do Agent Harness da TrueFoundry, os agentes referenciam modelos e ferramentas pelo nome, enquanto as credenciais residem centralmente nos gateways. Um agente que você não consegue identificar individualmente é um agente que você não consegue governar individualmente.

Um LLM pode julgar se uma ação atende à tarefa? Essa é a questão de pesquisa atual. O trabalho sobre TBAC no arXiv utiliza um juiz LLM consciente da incerteza e é transparente quanto aos problemas em aberto; a postura conservadora de produção baseia-se em limites determinísticos — pacotes, cotas, aprovações, escopos de curta duração — com o julgamento do LLM servindo como um sinal adicional, nunca como o único filtro para uma ação irreversível.

Referências

• Thomas, R.K. e Sandhu, R.S. — controle de acesso baseado em tarefas (TBAC), a base dos anos 90: permissões agrupadas em tarefas, privilégios mínimos para a duração de uma atividade. Parafraseado com os devidos créditos. 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) — o renascimento da pesquisa moderna, baseando-se no TBAC por seu "alinhamento natural com a natureza orientada a objetivos dos agentes de IA". https://arxiv.org/abs/2510.11414
• Cisco Outshift — "Tool, transaction, task-based access control (TBAC): Securing agentic AI beyond RBAC, ABAC, and ReBAC"; além de análises de especialistas da Oso ("Why RBAC Is Not Enough for AI Agents"), Kiteworks (ABAC vs. RBAC for agents) e tianpan.co (task-scoped credentials, request-context binding) — tudo parafraseado com os devidos créditos.
• Pesquisa da IBM sobre o custo de uma violação de dados (2025) e o Relatório de Exposição de Identidade da SpyCloud (2026), conforme relatado em publicações do setor de segurança de agentes — a lacuna empírica: incidentes de IA correlacionados com a falta de controles de acesso para IA e exposição em larga escala de credenciais de ferramentas de IA. Citado aqui por meio de análises secundárias do setor; consulte os relatórios primários para obter os números exatos.
• Documentação de Autenticação e Segurança do MCP Gateway da TrueFoundry — autenticação de entrada, controle de acesso na camada de gateway, servidores MCP virtuais, OAuth por usuário; Documentação do Agent Harness — sem credenciais em definições de agentes, injeção de credenciais, delegação, aprovações.
• TrueFoundry Agent GatewayeGateway de IA — cotas por agente, RBAC em nível de agente, logs de auditoria, políticas filtradas por metadados, guardrails e postura de implantação/conformidade (SOC 2 Tipo 2, HIPAA; SaaS/auto-hospedado/on-prem/air-gapped).

Ines é um composto ilustrativo, não uma pessoa, organização ou análise específica. O histórico de controle de acesso e as análises da era dos agentes foram parafraseados com os devidos créditos dos padrões, artigos e textos do setor citados; fragmentos citados possuem menos de quinze palavras e estão atribuídos. Estatísticas de terceiros (IBM, SpyCloud) são números relatados da pesquisa citada, conforme transmitidos em análises do setor. TBAC é um padrão de design e uma linhagem de pesquisa, não um padrão certificado, e nenhuma plataforma o oferece como um recurso único; as capacidades da TrueFoundry foram extraídas da documentação pública e páginas de produtos no momento da redação — verifique a documentação atual em truefoundry.com/docs. O trecho de configuração foi simplificado para facilitar a leitura e não representa o esquema literal do produto.

‍

‍