TBAC: Control de acceso basado en tareas para la era de los 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. Límites honestos: lo que TBAC no es (todavía)

Tres límites mantienen esto bajo un marco de credibilidad. Primero, ninguna plataforma ofrece TBAC como una casilla de verificación, TrueFoundry incluida; lo que existe son las primitivas ejecutables que el modelo requiere: paquetes con alcance definido, identidad por agente, credenciales delegadas, aprobaciones y auditoría. Ensamblarlos en una autorización por tarea es un trabajo de diseño que la plataforma facilita, no un interruptor. Segundo, la inferencia de tareas es genuinamente difícil. La forma más limpia de TBAC asume que el sistema sabe qué tarea se está ejecutando; los agentes difuminan eso, y la frontera del LLM como juez es prometedora pero temprana, con problemas abiertos que sus autores reconocen en torno a la incertidumbre y la manipulación: un juez que puede ser objeto de inyección de prompts es un guardia al que se puede convencer para que deje pasar. Tercero, los modelos más antiguos son fundamentales: el RBAC permanece como el límite exterior y el ABAC como contexto de tiempo de ejecución; eliminar roles para perseguir la pureza basada en tareas supone cambiar un control grueso auditable por uno fino no probado. TBAC es la capa más nueva de una pila, no una ideología sucesora.

8. Dónde termina esto: la tercera opción de Ines

La revisión de Ines concluyó con la tercera opción que ella quería, construida a partir de piezas documentadas. El agente de soporte obtuvo su propia identidad —una cuenta virtual, no una sesión humana prestada— con RBAC otorgando exactamente una cosa: un servidor MCP virtual que expone la búsqueda y el reembolso, dos herramientas seleccionadas de un servidor de veinte. Sus llamadas se ejecutan mediante delegación OAuth por usuario, por lo que solo toca lo que el contexto del cliente del ticket permite; su gasto está limitado por cuotas; y la única acción irreversible, el reembolso, se pausa para obtener aprobación humana por encima de un umbral. Cada invocación termina en un registro de auditoría que vincula la identidad, la decisión de política y la acción: la cadena causal que su proceso de respuesta a incidentes necesita. Sin roles de superusuario permanentes, sin agentes rotos: los permisos se ensamblan en torno al trabajo, limitados en alcance, duración y radio de impacto. La idea de los años 90, ejecutándose en infraestructura de 2026.

Ese es el arco honesto de TBAC. "¿Quién eres?" sirvió para el control de acceso durante cuarenta años porque los principales eran personas. Los agentes hicieron que "¿qué estás haciendo ahora mismo?" fuera la pregunta vinculante, y la respuesta no es un nuevo acrónimo que reemplace a los antiguos, sino los antiguos dispuestos correctamente, con construcciones de alcance de tarea en la parte superior, aplicadas en el único punto por el que ya pasan todas las llamadas a modelos y herramientas. La puerta de enlace se construyó para ser ese punto. La era de los agentes es lo que finalmente hizo que los años 90 tuvieran razón.

9. Preguntas frecuentes

¿Es TBAC un estándar como RBAC? No. RBAC tiene una estandarización formal; TBAC es un linaje de investigación —el trabajo de Thomas y Sandhu en los años 90— ahora revivido en la investigación de seguridad de agentes y en la literatura del sector (el enfoque de Cisco Outshift, el modelo TBAC juzgado por LLM en arXiv). Considérelo un patrón de diseño con un pedigrí sólido, no una especificación certificable. Su valor es la pregunta que obliga a plantear: ¿esta acción sirve a la tarea autorizada, dentro de sus límites?

¿Deberíamos reemplazar RBAC con TBAC para nuestros agentes? No, y ninguna fuente seria lo recomienda. RBAC sigue siendo el límite exterior auditable; las políticas de atributos manejan el contexto de tiempo de ejecución; las construcciones con forma de TBAC limitan el trabajo. El movimiento práctico es aditivo: identidades de agente, paquetes de herramientas por tarea, credenciales delegadas por usuario, puertas para lo irreversible y auditoría en un solo punto.

¿Cómo se aplica esto a RAG, no solo a las herramientas? La recuperación también es control de acceso: los documentos conllevan derechos, y los permisos del usuario que realiza la consulta —no la cuenta de servicio de la canalización— deberían limitar lo que devuelve la recuperación. Ese es territorio de ABAC/ReBAC en la capa de datos, complementado en la puerta de enlace mediante la delegación por usuario (las consultas de un agente llevan la identidad con alcance del usuario hacia abajo) y barreras de seguridad como el enmascaramiento de PII en la ruta de respuesta.

¿Cuál es el primer paso de mayor impacto? Dele a cada agente su propia identidad sin credenciales integradas. Las cuotas, el RBAC, la delegación y la auditoría se vinculan a la identidad, y es el estándar documentado en un entorno de ejecución gobernado: según la documentación de Agent Harness de TrueFoundry, los agentes hacen referencia a modelos y herramientas por nombre, mientras que las credenciales residen de forma centralizada en las puertas de enlace. Un agente que no puede identificar individualmente es uno que no puede gobernar individualmente.

¿Puede un LLM determinar si una acción sirve para realizar una tarea? Esa es la pregunta de investigación actual. El trabajo sobre TBAC en arXiv utiliza un LLM como juez consciente de la incertidumbre y es transparente sobre los problemas abiertos; la postura conservadora en producción consiste en límites deterministas —paquetes, cuotas, aprobaciones, ámbitos de corta duración—, utilizando el juicio del LLM como una señal adicional, nunca como el único filtro para una acción irreversible.

Referencias

• Thomas, R.K. y Sandhu, R.S. — controles de acceso basados en tareas (TBAC), la base de los años 90: permisos agrupados en tareas, privilegios mínimos durante la duración de una actividad. Parafraseado con atribución. 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) — el renacimiento de la investigación moderna, que se basa en el TBAC por su "alineación natural con la naturaleza orientada a objetivos de los 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"; además de análisis de profesionales de Oso ("Why RBAC Is Not Enough for AI Agents"), Kiteworks (ABAC vs. RBAC for agents) y tianpan.co (credenciales con ámbito de tarea, vinculación de contexto de solicitud) — todo parafraseado con atribución.
• Investigación de IBM sobre el coste de una brecha de datos (2025) y el informe de exposición de identidad de SpyCloud (2026), tal como se recoge en los informes del sector de seguridad de agentes — la brecha empírica: incidentes de IA correlacionados con la falta de controles de acceso a la IA y la exposición a gran escala de credenciales de herramientas de IA. Citado aquí a través de análisis secundarios del sector; consulte los informes principales para obtener las cifras exactas.
• Documentación de autenticación y seguridad de TrueFoundry MCP Gateway — autenticación de entrada, control de acceso en la capa de puerta de enlace, servidores MCP virtuales, OAuth por usuario; Documentación de Agent Harness — sin credenciales en las definiciones de los agentes, inyección de credenciales, delegación, aprobaciones.
• TrueFoundry Agent Gateway y puerta de enlace de IA (AI Gateway) — cuotas por agente, RBAC a nivel de agente, registro de auditoría, políticas filtradas por metadatos, barreras de seguridad y postura de despliegue/cumplimiento (SOC 2 Tipo 2, HIPAA; SaaS/alojado localmente/on-prem/air-gapped).

Ines es un compuesto ilustrativo, no una persona, organización o reseña específica. El historial de control de acceso y los análisis de la era de los agentes están parafraseados con atribución de los estándares, artículos y escritos del sector citados; los fragmentos citados tienen menos de quince palabras y están atribuidos. Las estadísticas de terceros (IBM, SpyCloud) son cifras reportadas de la investigación citada tal como se transmiten en los análisis del sector. TBAC es un patrón de diseño y un linaje de investigación, no un estándar certificado, y ninguna plataforma lo ofrece como una característica única; las capacidades de TrueFoundry se citan de la documentación pública y las páginas de productos en el momento de la redacción — verifique con la documentación actual en truefoundry.com/docs. El fragmento de configuración está simplificado para facilitar la lectura y no es un esquema de producto literal.

‍

‍