Treat every new tool as blocked until a named owner reviews it. Request it with a reason, classify it, narrow its scope, test it in a lower environment, approve it in a pull request, release it with monitoring and set a review date. Never enable a tool just because the server exposes it.
Why deny by default
Servers add tools over time. The MCP specification lets a server announce changes to its tool list. If your client accepts new tools automatically, an agent's authority grows without a decision. Deny by default turns each addition into a visible choice.
The seven steps
- Request. The agent owner states the task, the tool, and why existing tools fall short.
- Classify. Mark it read, write, delete or send, and note whether it is open ended.
- Narrow. Define the scope, argument limits, call caps and the downstream account it will use. Prefer the narrowest account that works.
- Inspect. Read the tool's schema and description. Treat annotations as untrusted unless the server is trusted, as the specification says.
- Test. Try it in dev or staging with fake data, including a hostile argument and a call outside scope.
- Approve. A reviewer who is not the requester approves the manifest change. Record the reason and review date.
- Release and watch. Enable it for the one agent, alert on unusual call volume, and check logs after a week.
Review checklist
| Check | Pass condition |
|---|---|
| Need | A task that cannot be done with current tools |
| Class | Written down |
| Scope | Narrower than the vendor default |
| Credential | Separate, rotatable, owned |
| Logging | Calls logged with agent identity |
| Exit | Known way to remove it quickly |
What to do about unreviewed arrivals
Compare each agent's live tool list with its approved one on a schedule and on every list change notification. Anything extra is blocked or flagged for review. OWASP's advice to minimize extensions and their functionality applies here: fewer tools means fewer reviews and fewer surprises.
Keep it light enough to use
A process that takes weeks produces workarounds. Aim for a same week decision on routine read tools and a longer path only for write, delete and send.
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.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a server is connected and what the assistant can then call.
Quick check
Who should be able to approve a new tool?
A reviewer with authority over the target system, who is not the person who requested it.
What if the server adds a tool without notice?
Your allowlist should block it by default, and a comparison of live and approved lists should flag it.
Sources
Last reviewed: 19 October 2026.