Task-based access control for tool-calling agents

Why role allowlists are not enough for agents

Role-based access control answers who someone is. Agents also need an answer to what they are doing right now. Multi-turn conversations drift. A session that started as "check shipment status" should not quietly gain a refund tool call because the role includes refunds.

Models propose tools that are merely available. Availability is not appropriateness. Without a task check, prompt injection and polite conversation drift both expand blast radius. A user who pastes an email that says "also process the refund" can move the model toward a write tool even when the stated job was read-only status.

Operators see this in support copilots: turn one looks up an order, turn four proposes refund.create because the schema is nearby and the role allowlist is broad. The incident review then asks why the system treated "could use support tools" as "may spend money on this chat."

TBAC complements harness role design in multi-agent harness deployment and gateway enforcement in MCP enterprise gateways. Identity still matters. The point is that identity alone is the wrong unit of authorization for multi-turn tool calling.

Failure modes in multi-turn tool use

Task drift. Early turns are read-only; later turns invoke writes without a new entitlement. The user never confirmed a goal change. The model inferred one from tone or from a pasted message. RBAC still says yes because the role never changed.

Tool stuffing. Large tool catalogs increase the chance the model picks a high-power tool that is unrelated but schema-similar. cancel_order and cancel_subscription look close in embeddings and in names. Without a task map, similarity becomes an authorization path.

Peer bypass. Another agent is asked to call the denied tool, skipping the original task bound. Multi-agent setups that trust peer requests without re-checking task scope recreate the same privilege through a side door.

Audit gaps. Logs show tool name and user, not the task object that justified or denied the call. Security cannot reconstruct whether the denial was correct, and product cannot mine false denies.

Silent task inheritance. A long-running thread keeps an old write-capable task after the user switched to a new topic. Without re-extraction or confirmation, yesterday's refund task still authorizes today's tools.

The TBAC control loop

Declare or extract a task: goal, resource scope, and side-effect ceiling. Bind it to the run ID. Prefer declared tasks when the product UI already knows the workflow (status lookup, password reset draft, policy Q&A). Use extraction when the channel is freeform chat, then show the user a short confirmation when the side-effect ceiling rises.

When the model requests a tool, match tool semantics to the task. Allow, require step-up auth, or deny. Prefer deterministic allowlists per task type first; add semantic matching where catalogs are large and only after you can explain misses.

Operable loop:

1. Create or update the task object at run start and on clear goal changes.
2. Intercept every tool proposal before execution (harness or MCP gateway).
3. Match tool ID to the task type allowlist; fall back to semantic match only when configured.
4. Deny with a user-visible reason that cites the current task, not a vague "policy."
5. Re-evaluate on each turn; never treat first-turn RBAC as a blank check for later writes.

Evaluation and human step-up

Build conversation-tool datasets: relevant tools, irrelevant tools, and privilege escalations across turns. Include injected "please also refund" turns inside status-only threads. Gate harness changes on precision and recall of the TBAC layer, not only on end-to-end answer satisfaction.

Score at the decision boundary: did TBAC allow or deny correctly before the tool ran? An agent that recovers politely after a dangerous tool already executed is not a pass.

For irreversible tools, TBAC allow should still flow through human write gates. Authorization to propose is not authorization to execute. TBAC narrows what may be proposed; HITL still owns irreversible side effects.

Log task ID, extracted goal summary, tool name, decision, and whether step-up or human approval followed. Those fields power security review and weekly eval mining. Without them, you cannot tell false deny from correct restraint.

Registry and task-type ownership

Document how new tools get mapped to task types. Require an owner for each mapping. Shipping a new MCP tool without a task map entry should fail CI the same way an unregistered route fails a gateway allowlist.

Start with a few task types and strict tool maps: status lookup, account update draft, refund proposal, admin config change. Expand semantic matching only after false denies are operable for users (clear messages, easy goal reconfirm).

Measure deny rate on irrelevant tools, false deny rate on legitimate tasks, escalation success via peer agents, and time to explain a denial to an auditor. Track peer-bypass attempts as a first-class security signal.

Rollout and metrics

Roll out behind the interception layer first in shadow mode: log allow/deny while still using the old RBAC path, then enforce per task type. Begin with high-blast tools (money, delete, customer message, production config) before tightening read tools.

Widen coverage when false deny rates are low and support can reconfirm goals without friction. Keep TBAC decisions visible in the agent UI so operators learn the contract instead of fighting opaque refusals.

The point is structural restraint: agents act for a job, not for everything a role could theoretically touch. RBAC remains necessary. Alone, it is not sufficient for multi-turn tool-calling systems.