Permissions that know
what your agent is doing
Traditional access control grants sweeping, permanent permissions tied to an identity. Devctrl grants only what the current task needs — and nothing more.
RBAC vs TBAC
RBAC is tied to who. TBAC is tied to what.
Role-based access was designed for humans clicking through UIs. Agents make thousands of autonomous decisions — they need access control that understands the task, not just the identity.
Role-Based
Permissions are bound to the identity of the user or service account. Once granted, they stay — across every call, every task, forever.
- Identity gets a role
- Role grants tools, permanently
- No sense of what's happening right now
- Wide damage if one account is compromised
Task-Based
Permissions are bound to the specific task the agent is performing. The same agent doing a different task gets different access.
- Identity gets a task
- Task carries context and scope
- Policies read task, context, and request together
- Exactly the permissions needed, nothing more
Security & Compliance
TBAC ensures that AI agents only receive the permissions they need for their current task. Every interaction is checked and logged by the policy engine — complete compliance, automatically enforced.
More efficiency
Within clearly defined rules, your agents act independently — fewer manual approvals, faster workflows and noticeably more productivity.
Context + Policy
The same tool, decided by task context.
Every task carries structured context. Your policies can read that context and make decisions no role-based system can.
Task
Task context
Request
Policy (CEL)
1request.tool.name == "email.send"2&& request.tool.args.customer_id3 == task.context.customer_id
Result
Same agent, same tool, same tenant — different outcomes because the task context changed.
Why it matters
Built for agents that actually act.
TBAC closes the gap between compliance requirements and agent autonomy: your agents move faster, your rules apply more tightly, and every decision stays provable.
Minimal rights
An agent can never act outside its task. If an account is misused, the damage stays bounded to a single task.
Context-aware denials
Policies read task context — not just identity. You can enforce business rules like 'only the customer this task was created for' in a few lines.
Audit at the task level
Every decision is logged against the task that caused it. Replay, audit, and debug any action back to the work that triggered it.
Stop granting forever. Grant per task.
See TBAC on your own use case. We'll help you model your first tasks and rules together.