Pull the agent's tool call log for a fixed window, list which granted tools it never used, and remove or time box those. Then narrow the scopes of the tools it did use to the ranges it actually touched. Review the result with the owner before you apply it.
The idea
Permissions are usually granted from guesses at the start of a project. Logs show behavior. The gap between the two is unused authority, which is risk with no benefit. Cloud providers do this for human and service roles already. AWS describes IAM Access Analyzer reviewing CloudTrail logs and generating a policy template containing the permissions an entity used in a date range of up to 90 days, which you then review and refine.
You can apply the same approach to agent tool grants, even without a cloud feature, using your own tool call logs.
What the log must contain
| Field | Use |
|---|---|
| Agent identity | Group calls per agent |
| Tool name and server | Compare with the manifest |
| Arguments summary | See scope actually used, such as which queue or folder |
| Result and errors | Find denied or failing calls |
| Timestamp and task ID | Spot seasonal tasks |
Steps
- Choose a window that covers a full work cycle. Thirty days misses a quarterly job, so check the calendar.
- List granted tools and count calls per tool in the window.
- Mark zero call tools as removal candidates. Ask the owner whether any belongs to a rare but real task.
- For used tools, look at argument ranges. If a file tool only ever read one folder, scope it to that folder.
- Apply changes in a lower environment first, then production.
- Watch for new denied calls for two weeks and keep a fast way to restore a grant.
Limits to know
Logs only show what happened, not what is needed. AWS notes its own tool does not capture action level detail for data events and says not to use policy generation for auditing, to use CloudTrail instead. The lesson carries over: a usage derived list is a starting point for review, and your audit log stays the source of truth.
Also remember that a prompt injected into an agent can make it call tools it never normally uses. Silence in the logs means the tool is unneeded or attackers have not tried yet. Both are reasons to remove it.
Make it routine
Repeat the exercise at each access review. Agents change as their prompts and tools change, so last quarter's right size becomes this quarter's drift.
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
How long a log window should I use?
Cover at least one full work cycle. For monthly or quarterly jobs, use 90 days or ask the owner about rare tasks.
Is it safe to remove a tool with zero calls?
Usually, after checking with the owner for rare tasks and keeping a quick way to restore it.
Sources
Last reviewed: 19 October 2026.
