> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devctrl.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# RBAC vs TBAC

> Why traditional role-based access control doesn't work for AI agents, and how Task-Based Access Control solves it.

Role-Based Access Control (RBAC) was designed for human users with predictable workflows. AI agents are different — they're dynamic, autonomous, and work across multiple tools in ways that static roles can't anticipate.

## Side-by-side comparison

|                     | RBAC                                     | TBAC                                              |
| ------------------- | ---------------------------------------- | ------------------------------------------------- |
| **Access based on** | Who the agent is (role/identity)         | What the agent is doing (task/intent)             |
| **Permissions**     | Static, bundled in roles                 | Dynamic, scoped per task                          |
| **Duration**        | Persistent (as long as role is assigned) | Time-limited (just-in-time, auto-expire)          |
| **Granularity**     | Coarse (role level)                      | Fine (task + context level)                       |
| **Audit trail**     | "Agent X has Support role"               | "Agent X accessed Customer Y's data for Ticket Z" |
| **Best for**        | Human users, predictable workflows       | AI agents, dynamic multi-step tasks               |

## Three scenarios

### 1. Support agent processing a refund

<Tabs>
  <Tab title="RBAC approach">
    The AI agent has a "Support Agent" role with access to:

    * All customer records
    * All billing data
    * All ticket management tools

    **Task**: Process a refund for Customer X's order #1234.

    **Problem**: The agent can access every customer's data, every invoice, and every billing tool — far more than this specific refund requires. If the agent hallucinates or gets manipulated, it has broad access to misuse.

    ```
    Agent: Support-Agent role
    Access: 500,000 customer records, all billing tools
    Needed: 1 customer record, 1 invoice, refund tool
    ```
  </Tab>

  <Tab title="TBAC approach">
    The agent has an identity with label `team: support`. It starts a task session for "process-refund" with context:

    ```json theme={null}
    { "customer_id": "cust_456", "order_id": "order_1234" }
    ```

    Policy: `task.context.customer_id == request.tool.args.customer_id`

    **Result**: The agent can only access Customer X's records and only use the refund tool. The token expires in 1 hour. Every access is logged with the task context.

    ```
    Agent: identity (team=support)
    Task: process-refund (customer_id=cust_456)
    Access: 1 customer record, refund tool only
    Duration: 1 hour, then auto-expires
    ```
  </Tab>
</Tabs>

### 2. CI/CD agent deploying to production

<Tabs>
  <Tab title="RBAC approach">
    The CI/CD agent has a "Deploy" role with access to all environments — staging, production, DR.

    **Problem**: A misconfigured pipeline or prompt injection could trigger deployments to production when only staging was intended.
  </Tab>

  <Tab title="TBAC approach">
    The agent starts a task session for "deploy-service" with context:

    ```json theme={null}
    { "environment": "staging", "service": "payment-api", "version": "v2.3.1" }
    ```

    Policy enforces: `task.context.environment == request.tool.args.target_env`

    **Result**: The agent can only deploy to staging. To deploy to production, it needs a separate task session with `environment: "production"` — which could require additional approval.
  </Tab>
</Tabs>

### 3. Data analyst querying customer database

<Tabs>
  <Tab title="RBAC approach">
    The analyst agent has a "Data Analyst" role with read access to all databases.

    **Problem**: The agent can query any table, including PII-heavy tables unrelated to the current analysis. No way to scope queries to the specific dataset needed.
  </Tab>

  <Tab title="TBAC approach">
    The agent starts a task session for "quarterly-report" with context:

    ```json theme={null}
    { "dataset": "sales_q1_2026", "allowed_tables": ["orders", "revenue"] }
    ```

    Policy: `request.tool.args.table in task.context.allowed_tables`

    **Result**: The agent can only query `orders` and `revenue` tables. PII tables, user data, and other datasets are inaccessible during this task.
  </Tab>
</Tabs>

## Why it matters for compliance

TBAC directly addresses regulatory requirements:

* **EU AI Act** — requires "appropriate technical and organisational measures" for AI systems. TBAC provides granular, auditable access control.
* **GDPR** — requires data minimization and purpose limitation. TBAC ensures agents only access data needed for the specific task.
* **SOC 2** — requires access controls and audit trails. TBAC provides both, with per-decision logging.

With RBAC, proving compliance means showing role assignments. With TBAC, you can prove exactly what each agent accessed, for which task, and whether it was within policy.

## When to use TBAC

TBAC is most valuable when:

* Agents perform **varied tasks** that need different tool/data access
* You need to **prove compliance** with per-action audit trails
* Agents access **sensitive data** that should be scoped to specific operations
* Multiple agents **collaborate** on workflows with different access needs

<Note>
  TBAC and RBAC aren't mutually exclusive. Identity labels in Devctrl serve a similar role to RBAC — you can use them for coarse-grained access. TBAC adds the task dimension for fine-grained, dynamic control.
</Note>

## Next steps

<CardGroup cols={2}>
  <Card title="Quickstart" icon="rocket" href="/quickstart">
    Try TBAC end-to-end in 15 minutes.
  </Card>

  <Card title="Policy examples" icon="book-open" href="/policies/examples">
    Real-world CEL policy patterns.
  </Card>
</CardGroup>