Tool-Based Access Control: The Missing Primitive for AI Agents

AI agents are reshaping how we think about access control. The shift is more architectural than incremental.

---

The scenario

Picture an AI agent running on your laptop. It has access to your email, your customer database, your payment processor, and your calendar. By the standards of every access control model written before 2024, this agent has one identity and one role. Call it "assistant." That role grants access to all four tools.

A single prompt injection attack, hidden inside a document the agent summarizes, tricks it into invoking the refund tool with attacker-controlled parameters. Money moves. The same role, in the same session, then sends a polished email from the user's account confirming everything is fine. Calendar invites smooth over the missing meeting where the issue would have surfaced. The agent did not exceed its authority. That was its authority.

The shape of the gap

Role-Based Access Control was designed for humans inside static org charts. Editors edit. Admins administer. Viewers view. It works because human roles change slowly, the action space is bounded, and the consequences of any single action are usually small. Attribute-Based Access Control extended this with context: time of day, IP address, device posture. Both models share an assumption that does not hold for agents. They assume the unit of capability is coarse and slowly changing.

For an AI agent, the unit of capability is the tool. A single agent identity may invoke fifty tools across a session. Each tool has wildly different blast radius. weather.lookup is harmless. payments.refund is consequential. database.delete_table is catastrophic. Granting all fifty under a single role is not access control. It is permission to do anything the agent can be argued into doing.

The granularity has to live at the tool, not at the role.

TBAC, defined

Tool-Based Access Control treats every tool invocation as a permission decision. Three primitives carry the model.

A tool catalog

Every tool the agent can invoke, registered with annotations describing its semantics: read-only, destructive, idempotent, reaches external systems. Unknown tools encountered at runtime default to the most restrictive interpretation until a human reviews them.

A rule set scoped per tool

Rules match on the tool itself, but also on resource (which database, which mailbox), method (read, write, delete), tenant (which customer's data), and tag (sensitive, financial, public). The match cascade resolves from most specific to least specific, with the most specific matching rule winning.

A decision returned per invocation

Allowed, requires_approval, or disabled. Decisions happen in the moment, against live policy. Cached decisions defeat the purpose; stale rules are worse than no rules.

Tool-Based Access Control does not replace your identity provider. The agent still authenticates as itself. The user still authenticates as themselves. TBAC sits between authentication and execution, answering the question those layers cannot: given that this agent acting on behalf of this user is allowed to be here at all, is this specific tool invocation allowed right now?

The lineage

The acronym TBAC has appeared in academic literature before. In 1997, Roshan Thomas and Ravi Sandhu published "Task-Based Authorization Controls," proposing that authorization should follow the lifecycle of tasks rather than static role assignments. The paper was prescient and largely dormant for two decades, because the systems of that era did not have a concrete object to point at when they said "task." Tasks were modeled abstractly, as workflow steps in enterprise systems.

In 2026, with the Model Context Protocol making tools explicit, named, versioned, and registered, the abstract object the 1997 paper reached for finally exists. Tools are tasks made concrete. Tool-Based Access Control is the modern instantiation of what Task-Based Access Control was reaching for: the same architectural insight, applied to a primitive that did not yet exist when the original paper was written.

The lineage matters because it grounds the model in nearly thirty years of access control research, not in a marketing claim. TBAC is not new theory. It is old theory finally meeting the right substrate.

Why this matters now

Three forces converged in the last eighteen months and made tool-level governance unavoidable.

MCP standardized tool registration

Before MCP, every agent framework had its own tool-calling convention. Agent A's send_email was structurally different from Agent B's send_email. Cross-framework governance was not possible because there was nothing to govern uniformly. MCP gave the industry a shared shape.

Auto-discovery accelerated tool catalogs beyond human review speed

An agent connecting to a new MCP server can pick up dozens of tools in a single handshake. Humans cannot pre-register tools fast enough. The governance system has to default to safe, gate the unknown, and let humans triage at their own pace.

Real consequences entered the loop

Agents are moving money, sending production emails, modifying databases, and deploying code. The class of attacks documented in early 2026 (prompt injection causing tool misuse, supply chain compromises in plugins, parameter manipulation across legitimate tool calls) all share a property. The tool itself was the right place to apply policy, and there was no native place to put it.

What TBAC requires in production

A TBAC implementation that holds up under real traffic has to do several things at once.

It needs a tool catalog with conservative defaults. Tools that have never been seen before should resolve to requires_approval automatically, with annotations interpreted at their most restrictive (assume destructive, assume open-world, assume non-idempotent) until a human reviews and explicitly grants. Letting unknown tools default to allowed is the same mistake networks made in the 1990s with default-open firewall rules.

It needs resource and parameter scoping. A rule that says "send_email is allowed" is too coarse. The same rule scoped to "send_email when the recipient domain matches the user's domain" is meaningfully safer without being onerous. Most agent traffic stays within narrow parameter envelopes by nature; the rules should match that shape.

It needs approval routing on a channel separate from the agent's host. If the agent runs on a laptop and the approval prompt appears on the same laptop, a compromised laptop approves itself. The phone, the watch, a separate enrolled device, or a teammate are all valid second channels. The mechanism is channel separation, not necessarily a second person.

It needs tamper-evident audit. Every decision, every approval, every execution recorded in a store the calling host cannot edit. After an incident, the audit trail is what makes detection, response, and recovery possible. Before an incident, it is what compliance buyers, cyber insurers, and security reviewers ask about first.

These are not optional features layered on top. They are the minimum surface of any TBAC system that can be relied on for production traffic.

Adjacent concepts: neighbors, not competitors

Tool-Based Access Control is not the only model in this space and it does not have to be. Adjacent layers solve adjacent problems.

Intent-Based Access Control

Articulated in recent literature on AI agent security, Intent-Based Access Control focuses on validating user intent before any tool is invoked. The agent parses what the user asked for into structured intent tuples; the access layer checks those tuples against permitted actions. Intent-based control catches the prompt injection at the front of the pipeline, before the agent has chosen tools. TBAC catches the unauthorized invocation at the back of the pipeline, regardless of what the agent decided. The two compose cleanly. Intent validation reduces the surface of bad agent decisions; tool gating ensures bad decisions cannot execute.

Transport-layer policy

MCP tool ACLs at the network gateway sit one layer below TBAC. They can block tool calls based on identity and tool name as the request crosses the wire. This is useful infrastructure but operates at a different layer than TBAC. The gateway sees what is in the request, not what the request will do, and it cannot route approvals or maintain a unified audit across heterogeneous agent runtimes. Gateway ACLs are a control point. TBAC is a control plane. Both are valid; they answer different questions.

Role-Based Access Control

RBAC still applies to the human side of the system. Who can edit which permission rules? Who can approve which classes of action? Who can view which audit records? Those are role decisions. TBAC governs the agent; RBAC governs the humans governing the agent.

Closing

Return to the scenario at the opening. The agent is hit with the same prompt injection attack. It tries to invoke payments.refund with attacker-controlled parameters. The tool is registered, but the rule for the payments resource is requires_approval with a separate channel destination. An approval prompt appears on the user's phone with full parameter detail: refund amount, recipient, originating session. The user looks at it for two seconds, sees the recipient is unfamiliar, denies. The refund never executes.

The cover-up email tries to send. The send_email rule is scoped to recipients in the user's own domain. The attacker's address fails the scope check. The cover-up email never sends.

The audit log records both attempts in tamper-evident form. The user, alerted by the strange approval prompt, investigates. The compromise is contained at the first attempted action rather than after the third or fourth.

That is the shape of agent security under Tool-Based Access Control. The right granularity, decided in the right place, at the right moment, with a record that survives.