On this page
Review an AI agent tool call by checking the proposed action, target, account, data, and likely side effect. Approve the narrow operation you understand. If a request is too vague to inspect, ask the agent to produce a concrete plan or preview before it runs.
These practices are for operators deciding whether an agent should execute a particular action. They do not rank security products or replace access controls. The worked examples are illustrative.
1. Read the arguments, not just the explanation
An agent might describe a command as “clean up temporary files” while the arguments name a broad directory. Read the actual path, resource identifier, recipient, or query. Check where the operation will run and which account will perform it.
For a shell command, examine the complete command, including chained commands, redirection, and scripts it invokes. If the request runs an unfamiliar script, review the relevant script before approving its execution. A reassuring natural-language summary cannot establish what the command does.
For an API call, identify the method and its documented effect. A preview should remain noncommitting; do not assume that an endpoint is harmless because its name sounds like a read. Some tools create persistent drafts or start jobs as part of a request.
2. Check the exact destination
Consider an agent preparing a customer email. The message may be correct while the recipient is wrong. Review the address, attachments, final authored text, and sending account as one decision. A previous approval to draft that message does not necessarily authorize sending it.
The same principle applies to a database change. “Update the test record” needs an environment, database, record key, and proposed change. If those fields are missing, keep the operation pending rather than guessing from the surrounding conversation.
3. Match approval scope to the task
A one-time action and a persistent permission rule have different consequences. Before selecting an option equivalent to “always allow,” ask which future arguments and targets it covers. Prefer a narrow rule when repeated work is predictable; keep unusual or high-impact changes subject to a fresh decision.
Claude Code's permission documentation distinguishes tool rules and persistent approval behavior. Check the current semantics of the client you use. Identically worded buttons in different clients need not grant identical access.
Do not use frequent prompts as a reason to grant an entire server unrestricted access. Remove unused tools, narrow credentials, and separate routine reads from sensitive changes. That reduces avoidable decisions without turning every future action into an approved one.
4. Treat tool definitions and results as inputs to inspect
MCP tool metadata helps a client describe a tool; it is not proof that the server enforces the claimed limits. The OWASP MCP security checklist recommends reviewing complete tool definitions and re-reviewing changes. It also warns that tool annotations are hints, not enforcement.
A changed schema, server identity, or credential scope should trigger a new inspection. A definition hash can reveal a changed definition, but an unchanged hash does not prove that the server's implementation or behavior stayed the same.
Tool output can contain untrusted instructions. A retrieved document telling the agent to send a secret elsewhere does not become authorized because an approved tool returned it. Evaluate the next proposed action against the user's task and the system's access rules.
5. Use a short decision record
| Field | Example for a disposable test |
|---|---|
| Requested action | Write a summary file. |
| Target | The named output file in the test workspace. |
| Identity | The dedicated test account. |
| Data | Synthetic invoice totals, with no customer data. |
| Scope | This write only; no deletion or external delivery. |
| Decision | Approved by the designated operator at the recorded time. |
| Result | The file exists with the expected content, checked separately. |
The last row matters. An approval receipt proves a decision, not execution. If a tool times out after a write, inspect the target before repeating the request. Record an uncertain result as uncertain until there is evidence of what happened.
6. Keep high-impact authority outside routine approval
A working tool can still propose an action its operator is not authorized to approve. Payments, access grants, legal commitments, and production changes may need a separate owner or process. Follow that process even if the agent has already assembled the request.
For ordinary work, make the next permitted step explicit. “Prepare the patch but do not deploy it” gives the agent useful work to finish while the deployment decision stays with the responsible person. Avoid indefinite holds when a safe, authorized part of the task can proceed.
Using HOL Guard during review
HOL Guard provides policy decisions and review evidence on supported action surfaces. Its role depends on the integration and event; it does not make every remote API or local process observable. Inspect the current integration information before relying on a particular approval path.
Combine review with restricted access to secrets and the underlying service's permissions. An operator should be able to explain both what was approved and what the agent could never access in the first place.
Check the surrounding controls
Review works best when the agent already has a task-scoped permission plan. Before relying on a new configuration, use the safe permission-testing worksheet to distinguish a model refusal from an enforced boundary.
Sources checked November 2, 2026. Examples are hypothetical. No approval workflow eliminates human error or establishes universal protection.
