Tool Use
Advanced 13 min read Tool Use

Tool Governance

Policy between intent and action

Governance decides which tools exist, who may invoke them, and with what limits — permission model, approval flow for writes, rate caps, and audit. It's the policy layer between model intent and real systems.

governancepolicyapprovalrbacrate limitaudit
Prerequisites: Tool Use Overview
Before we start

What you will learn

  • Model tools with read/write permissions
  • Add approval gates for destructive actions
  • Audit tool use for compliance and eval
Introduction

What is this?

Tool governance is the policy layer: every tool declares a permission class (read vs write vs admin); users and sessions hold roles; writes go through approval (human) or policy (max amounts, allowlists); rate limits and budgets cap spend; and every call is audited. The model proposes — governance disposes.

Motivation

Why do you need it?

  • Trust is earned in explicit checks, not model judgment.
  • Approvals convert autonomy into controlled delegation.
  • Rate/budget caps make tools financially and operationally bounded.
  • Audit logs train evals, answer disputes, and satisfy compliance.
Think about it

Mental model

Imagine

Signing authority on company accounts

Think of

Tool governance

Anyone can check balances (read tools); only managers sign transfers (write approval); the board sets limits (caps); controllers audit every signature (logs). The strength isn't in how well the machine asks — it's that approval and limits exist at every level.

Mechanics

How it works

  • Classify each tool: read / write / admin.
  • Map roles ↔ tools, scoped by tenant/user.
  • Route destructive or costly calls through an approval step.
  • Enforce per-call, per-session rate + budget caps.
  • Log identity, args, decision, result for every call.

Governance layers.

Request
Identity
Policy
Approval
Execute
Real world

In production

  • Enterprise copilots distinguish read-only assistants from write-enabled ones.
  • Fintech tools put send-payment behind confirmation + limits.
  • Admin surfaces require explicit permission elevation per session.
Guidelines

Best practices

  • Default deny; grant tool access explicitly.
  • Keep write tools behind approval or human confirmation.
  • Enforce per-session budgets, not just per-call.
  • Make every decision loggable and evaluable.
Watch out

Common mistakes

  • One 'super-tool' that writes everything.
  • Approval by 'trust the model this time' with no caps.
  • Audit logs nobody reads and evals never use.
Root cause analysis

Common issues

Error
A write slipped through governance
Root cause

Tool misclassified as read

Fix

Audit classification; default-deny new tools until reviewed.

Error
Users blocked from legit actions
Root cause

Rights mapping too coarse

Fix

Refine scopes (per-tenant, per-resource) and document.

When things break

Debugging tips

  • Over-blocking → check role mapping; users need scoped upgrades.
  • Approval latency hurts UX → batch writes or pre-approve recurring ones.
  • Caps hit repeatedly → budget too tight vs task; analyze norms.
Interviews

Interview checkpoint

Practice

Hands-on lab

Tool Access Policies
25 min · intermediate
In progress
Objectives
  • Model tools with allowed scopes
  • Gate dispatch on a policy check
  • Keep an audit trail of denied calls

Tool Access Policies

25 min · intermediate

0/3 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

The governance default should be…

2

Write tools can ride on model judgment alone.

Go deeper

Official documentation

RBAC pattern (AWS)
docs