Classify each agent tool by the verb it performs on a real system: read, write, delete or send. Read changes nothing, write changes data you can restore, delete may be permanent, and send leaves your boundary entirely. Give each class a default control, then adjust per tool.
Why verbs beat tool names
Tool names are chosen by whoever wrote the server. A tool called "sync" might read, write and delete in one call. Classifying by effect, not by label, keeps the review honest. Read the tool's input schema and, better, test it against a sandbox before you decide.
The OWASP guidance on excessive agency lists "excessive functionality" and "excessive permissions" as two separate root causes. A verb table helps with both: it shows which tools exist that the task never needed, and which ones hold more power than the task needs.
The four classes
| Class | What it does | Can you undo it? | Default control |
|---|---|---|---|
| Read | Returns data, changes nothing | Not applicable, but data can leak | Scope to the task's data, log calls |
| Write | Creates or edits records | Usually, from history or backup | Allow in non production, review in production |
| Delete | Removes records or resources | Often not | Human approval every time |
| Send | Emails, posts, pays, calls an outside API | Almost never | Human approval, recipient and amount limits |
Read is not harmless. A read tool that returns customer records to a model, which then writes them into an outbound message, is a data leak with two innocent looking steps. Treat read on sensitive data as its own sub class.
Steps to classify your tools
- List every tool each agent can call. Include tools that arrive through an MCP server you did not write.
- For each tool, write the verb in one word and the system it touches.
- If a tool does more than one verb, rate it by the riskiest one, or ask the owner to split it.
- Mark tools that combine classes, such as "read a file and email it". These need the strictest rule of their parts.
- Record the class in your agent registry so reviewers see it without re-reading schemas.
- Re-classify when a server announces a changed tool list. The MCP specification lets servers send a list changed notification, so the set you reviewed can move.
Using the table in practice
Start with approval on delete and send, and watch the logs. If a class generates hundreds of approvals a week with no rejections, narrow the tool (for example, delete only drafts) before you remove the approval. Narrowing shrinks the blast radius, which is a better fix than approving less often.
Safeguard offers MCP Guardrail and agent identity for applying this kind of policy to agent tool calls, and you can run a free scan of your own repositories at gold.safeguard.sh/scan. Autonomous fix pull requests are off by default, and every category starts on Manual.
Quick check
Is a read only tool always safe to allow?
No. It can expose sensitive data to the model, and the model can pass that data on through a send tool. Scope what it can read, and log the calls.
What if one tool does several things?
Rate it by its riskiest action, or ask the owner to split it into narrower tools.
Sources
Last reviewed: 19 October 2026.
