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

# Task-Based Access Control

> Grant agents only the permissions their current task requires — scoped, time-limited, and auditable.

Traditional access control asks "who is this agent?" Devctrl asks "what is this agent trying to do?"

**Task-Based Access Control (TBAC)** grants permissions based on the current task, not the agent's role. Permissions are bundled per task, granted just-in-time, and automatically expire when the task is done.

## RBAC vs TBAC

<Tabs>
  <Tab title="RBAC (Traditional)">
    **Principle**: "Who is this user, and what role were they assigned?"

    * Access is based on the actor's identity (role)
    * Roles bundle static permissions — "Support Agent", "Admin"
    * Permissions persist as long as the role is assigned
    * Works well for predictable, human workflows

    **Example**: A support agent with the "Support" role can access **all** customer data, invoices, and tickets — even when resolving a single ticket.
  </Tab>

  <Tab title="TBAC (Devctrl)">
    **Principle**: "What task is this agent performing, and what does it need?"

    * Access is based on the current task (intent)
    * Permissions are bundled per task, granular, and time-limited
    * Tokens expire when the task completes (just-in-time)
    * Built for dynamic, multi-step AI agent workflows

    **Example**: An agent resolving a refund for Customer X gets **temporary read access** to exactly that customer's booking — not all customer data.
  </Tab>
</Tabs>

## Why RBAC breaks down for AI agents

AI agents are fundamentally different from human users:

* **Dynamic tasks** — agents plan and execute multi-step workflows on the fly. Static roles can't anticipate every combination of tools an agent might need.
* **Over-provisioning** — to avoid breaking agents, teams grant broad access. A "Support Agent" role might include tools the agent rarely uses, creating unnecessary risk.
* **No task context** — RBAC has no concept of what the agent is currently doing. It can't scope permissions to a specific customer, ticket, or transaction.
* **Audit gaps** — you know the agent has the "Support" role, but you can't prove it only accessed what it needed for a specific ticket.

## How TBAC works in Devctrl

TBAC combines three concepts: **identities**, **task sessions**, and **policies**.

```
Agent authenticates          Agent starts a task         Gateway checks every call
with credential       →      and gets a task token  →    against policies
(identity)                   (scoped context)            (CEL rules)
```

1. **Identity** — the agent authenticates with a bearer token tied to an identity. The identity carries labels (like `team: support`) but no broad permissions.

2. **Task session** — when the agent begins a task, it creates a task session with specific context (like `customer_id: "cust_456"`). The session returns a time-limited token.

3. **Policy evaluation** — on every tool call, the gateway evaluates CEL policies against the full context: identity labels, task context, and the requested tool. Only calls that match the policy are allowed.

## Example: support agent refund

<Tabs>
  <Tab title="Without Devctrl (RBAC)">
    ```
    Agent: "Support Agent" role
    Access: All customers, all invoices, all tickets
    Risk: Agent can read any customer's data, even unrelated ones

    "Check refund for Customer X"
    → Agent has default access to ALL customer and billing data
    → No way to prove it only looked at Customer X
    ```
  </Tab>

  <Tab title="With Devctrl (TBAC)">
    ```
    Agent: identity with label team=support
    Task: "process-refund" with context { customer_id: "cust_456" }
    Policy: task.context.customer_id == request.tool.args.customer_id

    "Check refund for Customer X"
    → Agent gets temporary access to Customer X's booking only
    → Token expires after 1 hour
    → Every access is logged with full context
    ```
  </Tab>
</Tabs>

<Note>
  TBAC doesn't replace identity. It adds a task dimension to authorization decisions. The agent still authenticates with a credential — but what it can do depends on the task it's performing, not just who it is.
</Note>

## Next steps

<CardGroup cols={2}>
  <Card title="Identities" icon="id-card" href="/concepts/identities">
    Learn how agent identities work — credentials, labels, and allowed tools.
  </Card>

  <Card title="Tasks" icon="list-check" href="/concepts/tasks">
    Define tasks with context schemas and scoped permissions.
  </Card>
</CardGroup>