RBAC vs TBAC

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

RBAC approach
TBAC 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

The agent has an identity with label team: support. It starts a task session for “process-refund” with context:

{ "customer_id": "cust_456", "order_id": "order_1234" }

Policy: task.context.customer_id == request.tool.args.customer_idResult: 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

2. CI/CD agent deploying to production

RBAC approach
TBAC 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.

The agent starts a task session for “deploy-service” with context:

{ "environment": "staging", "service": "payment-api", "version": "v2.3.1" }

Policy enforces: task.context.environment == request.tool.args.target_envResult: 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.

3. Data analyst querying customer database

RBAC approach
TBAC 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.

The agent starts a task session for “quarterly-report” with context:

{ "dataset": "sales_q1_2026", "allowed_tables": ["orders", "revenue"] }

Policy: request.tool.args.table in task.context.allowed_tablesResult: The agent can only query orders and revenue tables. PII tables, user data, and other datasets are inaccessible during this task.

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

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.

Get Started

Core Concepts

Console Guide

Gateway

Policies

Side-by-side comparison

Three scenarios

1. Support agent processing a refund

2. CI/CD agent deploying to production

3. Data analyst querying customer database

Why it matters for compliance

When to use TBAC

Next steps

Quickstart

Policy examples

​Side-by-side comparison

​Three scenarios

​1. Support agent processing a refund

​2. CI/CD agent deploying to production

​3. Data analyst querying customer database

​Why it matters for compliance

​When to use TBAC

​Next steps

Quickstart

Policy examples

Side-by-side comparison

Three scenarios

1. Support agent processing a refund

2. CI/CD agent deploying to production

3. Data analyst querying customer database

Why it matters for compliance

When to use TBAC

Next steps