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

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.

​
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

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

​
Next steps

Identities

Learn how agent identities work — credentials, labels, and allowed tools.

Tasks

Define tasks with context schemas and scoped permissions.