Share
AI/ML
7 min read
Share
Artificial intelligence (AI) has changed the game in access control approaches.
We’re entering a world where AI Agents are consuming APIs, booking travel, reconciling invoices, deploying software, and chaining together services at machine speed. These agents don’t think in roles, attributes, or relationships. They function in units of work, or tasks.
And that’s why our existing access control models will fail them.
We must expand identity and access management (IAM) practices beyond role-based (RBAC), attribute-based (ABAC) and relationship-based (ReBAC) access control models to include controls around specific actions. This is where TBAC—tool, transaction, task-based access control—comes in. By providing fine-grained access control over individual units of work, TBAC ensures that agents are appropriately permissioned.
Before exploring the details of TBAC, let's first consider why a new access control model is necessary.
Over the last three decades, enterprises have expanded their access control approaches. RBAC established the foundation, while ABAC and ReBAC models emerged to address increasingly sophisticated permission structures. However, these approaches all have a central flaw—they are designed to control computer system access for individual users, not large numbers of dynamic and ephemeral agents.
Role-based access control (RBAC): This is designed for humans with static job functions. Agents don’t have jobs, instead they work on completing a task or achieving a goal. If an agent inherits a user’s role, it either:
Attribute-based access control (ABAC): Adds context to the permission model using attributes such as time, device, and department. As the number of attribute combinations increases, policies quickly become complex, opaque to auditors, and difficult to manage at the scale expected of agentic systems.
Relationship-based access control (ReBAC): ReBAC was designed for human relationships—specifically, to define who manages, collaborates with, or shares with whom. While it introduces more dynamism to the permission model, ReBAC still relies on a relatively static relationship graph. However, the relationships of AI agents change with each new assignment. ReBAC is not dynamic enough to accommodate the fluid and ephemeral nature of AI agents.
Organizations are increasingly using delegation and impersonation to provide agentic software access to their systems. These techniques muddy accountability as it becomes very difficult to track responsibility, audit actions or investigate security incidents. Furthermore, when an agent impersonates a user, it may gain access to resources or perform actions beyond what is strictly necessary to complete the assigned task.
When a new employee joins a company, they need a laptop. At first glance, the process seems simple: someone needs to buy the laptop, charge it to the right budget, and make sure finance has the record. However, when you delegate this task to an AI agent, the straightforward nature of the request starts to unravel. What appears to be a routine task for a human reveals layers of interconnected processes, each with its own rules, exceptions, and dependencies, posing a significant challenge for agents to execute seamlessly.
On paper, the workflow is simple:
But here’s the catch: agents don’t fit neatly into today’s access control world.
If you ask the agent to impersonate the new employee, it stalls out immediately. The employee doesn’t have permission to see budget data or access the necessary procurement tools. The agent is stuck at step one.
Alternatively, if you delegate the finance manager role to the agent, it gains access to way too much information such as confidential forecasts, payroll data, and vendor contracts. While the agent may be able to complete the work of ordering a laptop, it was massively over-permissioned while doing so.
Either way, the access control model fails. The agent has too few or too many permissions. Traceability is lost. Was it the employee, the manager, or the agent who triggered the budget query and purchase order?
This laptop example is just an illustration of the mismatch between user-centric access models (built for humans with roles, titles, and relationships) and agent-centric workflows (driven entirely by tasks).
Here’s the punchline of our laptop story: the problem wasn’t the task itself. Provisioning a laptop is straightforward. The problem was the access model.
Traditional approaches—RBAC, ABAC, ReBAC—were all designed for people. They ask questions like:
And for humans, these approaches work fine. A finance manager has access to budgets. An engineer has access to staging clusters. A recruiter has access to candidate records.
However, they don’t work for autonomous agents. Agents don’t have a job title, an org chart, or a “home department.” It’s defined entirely by the work it’s doing at the moment. That’s why user-centric models break down.
So, what if we flipped the script? Instead of authorizing the person (real or impersonated), we authorize the work itself.
Task, tool, and transaction-based access control, or TBAC, enables fine-grained, contextual, and auditable access controls. This ensures trust, compliance, and security across all AI-driven operations.
Think of TBAC as a funnel that narrows broad intent into precise, auditable action.
Together, these three dimensions define a temporary, just-in-time permission envelope:
This is the opposite of delegation or impersonation. Rather than pretending the agent is a user, TBAC focuses on the agent's work.
Leaders need to understand how TBAC addresses gaps left by traditional access controls. Here are five key reasons why TBAC matters for your organization:
Agents can act at machine speed, across domains, and across enterprise boundaries—but always operate inside structured guardrails that ensure each step is authorized, auditable, and reversible.
No more “all-or-nothing” role assignments. Permissions exist only for the duration and specificity of explicitly defined tasks and tools. This approach dramatically reduces the blast radius if something goes wrong.
Rather than ripping out your existing RBAC or ABAC capabilities, TBAC layers on top of them. Roles and attributes continue to provide structure. TBAC injects workflow awareness. Together they enable identity governance that scales to autonomous operations and across human-agent collaborations.
When auditors ask, “Who did what, when, and why?” RBAC and ABAC often give you a name and a role. TBAC gives you the task ID, the set of tools used, and the exact transactions executed. That kind of transparency builds trust faster—and more securely.
Whether you’re building MCP-based agent ecosystems, DevOps bots, or supply-chain orchestration systems, TBAC ensures that the next generation of autonomous tooling doesn’t become the biggest vulnerability in your enterprise.
TBAC is here to complement, not replace RBAC, ABAC and ReBAC. TBAC adds the language of work to your identity and access ecosystem for agentic services.
The more granular model allows you to ask questions you could never ask before such as:
TBAC is an important step to ensuring agents have the right permissions in place. Traditional access models which are designed around human identity aren’t enough for agents. If you want to truly secure agents, you need trusted, verifiable agent identity.
Join our upcoming webinar to see how the AGNTCY Identity framework builds trust and security for agentic software. Register for The key to autonomous AI Agents and MCP servers you can trust webinar today.
Get emerging insights on innovative technology straight to your inbox.
See how SoftServe used AGNTCY to overcome intelligent video monitoring challenges with scalable, modular, and real-time solutions.
* No email required
The Shift is Outshift’s exclusive newsletter.
Get the latest news and updates on agentic AI, quantum, next-gen infra, and other groundbreaking innovations shaping the future of technology straight to your inbox.
