VIII · Safety & ControlEmerging★

Progressive Tool Access

also known as Need-to-Use Tool Access, Graduated Tool Permissions

Grant tool permissions on a need-to-use basis, starting minimum and expanding only as the agent proves competency, mirroring how humans earn system access.

Context

A new agent goes into production. Default is to provision all its tools at once: full DB access, full email, full file system, full payment. The agent has not yet demonstrated competency on any of them. The tool-access-paradox kicks in: capability and risk both scale with tool count.

Problem

Front-loaded tool provisioning maximizes blast radius before competency is established. An early agent mistake on a tool it didn't need yet causes a high-cost incident. The standard mitigations (sandbox-isolation, policy-gates) are runtime — they don't address the design choice of which tools to grant in the first place.

Forces

  • Graduated provisioning slows agent's reach to full capability.
  • Defining 'proved competency' per tool is engineering work.
  • Rolling back provisioning after escalation is operationally awkward.

Example

An inventory agent is provisioned Tier 1 on stock-query, Tier 1 on order-DB. After 30 days with zero incidents and 99% query success it earns Tier 2 on order-DB (write to staging). After 60 more days clean it earns Tier 3 on order-DB (production write). Meanwhile a sibling agent has an incident on Tier 1 stock-query (returned wrong data, caused downstream confusion) and is held at Tier 1 until incident root cause is resolved.

Diagram

Solution

Therefore:

Define provisioning tiers per tool: Tier 0 — none; Tier 1 — read/query only; Tier 2 — write to staging/sandbox; Tier 3 — full production write. Move the agent up tiers based on demonstrated metrics (success rate, no incidents, monitored time-in-tier). Track per-tool tier. Pair with tool-loadout, tool-loadout-hotswap, sandbox-isolation, policy-gated-agent-action, three-tier-autonomy-portfolio.

What this pattern forbids. No tool is provisioned at a tier the agent has not earned via measured competency; tier downgrade on incident is automatic, not negotiated.

And the patterns that stand alongside it, or against it —

  • complementsTool Loadout★★— Select a small task-relevant subset of available tools per request rather than exposing the full registry to the model.
  • complementsTool Loadout Hot-Swap✕— Anti-pattern: add or remove tool definitions during a running task so the tool set the model sees changes from turn to turn.
  • complementsSandbox Isolation★★— Run agent-emitted code or actions in a contained environment with restricted filesystem, network, and process privileges.
  • complementsPolicy-Gated Agent Action (KRITIS)★— Each agent action passes through a policy gate (NIS2, EU AI Act, BSI rules) and is tagged with Run ID + Model Digest + Policy Hash for WORM-audit reconstruction.
  • alternative-toStatic Role for a Dynamic Agent✕— Anti-pattern: authorize a goal-driven agent with static, login-time, role-based privileges, so its standing permissions persist between and beyond tasks, forcing a choice between over-granting broad access and blocking the agent mid-task.
  • alternative-toMonotonic Privilege Confinement★— Let a task-derived action policy change during a run, but admit an update automatically only when a decision procedure proves it narrows the permitted set, so privileges shrink freely and widen only on approval.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

Used in frameworks

References

Provenance