Skip to main content
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

RBACTBAC
Access based onWho the agent is (role/identity)What the agent is doing (task/intent)
PermissionsStatic, bundled in rolesDynamic, scoped per task
DurationPersistent (as long as role is assigned)Time-limited (just-in-time, auto-expire)
GranularityCoarse (role level)Fine (task + context level)
Audit trail”Agent X has Support role""Agent X accessed Customer Y’s data for Ticket Z”
Best forHuman users, predictable workflowsAI agents, dynamic multi-step tasks

​
Three scenarios

​
1. Support agent processing a refund

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

​
2. CI/CD agent deploying to production

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.

​
3. Data analyst querying customer database

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.

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

​
Next steps

Quickstart

Try TBAC end-to-end in 15 minutes.

Policy examples

Real-world CEL policy patterns.