An agent tool permission manifest is a short, version controlled file that states exactly which tools one agent may call, with what scopes, limits and approval rules, and who owns it. It turns "what can this agent do?" into a diff you can review and an auditor can read.
Why a file and not a settings page
Settings pages change silently and keep no history. A file in a repository has an author, a reviewer and a timestamp on every change. That history is audit evidence you get for free. It also lets you compare the approved list with what the agent sees at runtime, which is how you spot drift.
Fields to include
| Field | Example value | Why it matters |
|---|---|---|
| Agent name and ID | support-triage-agent | Ties the file to one identity |
| Owner and sponsor | named team and person | Someone answers for it |
| Environment | production | Prevents a dev list leaking upward |
| Tool name and server | tickets.search on helpdesk server | Exact allow entry |
| Class | read | From your verb table |
| Scope | read tickets for one queue | The narrowest grant that works |
| Limits | 30 calls per task | Contains loops |
| Approval rule | none, or named approver group | Who must say yes |
| Expiry or review date | next review quarter end | Stops stale grants |
| Reason | needed to summarise open tickets | Lets reviewers question it |
Sample layout
Keep it plain. A YAML or JSON file works. The shape is a header with agent, owner and environment, followed by a list of tool entries with the columns above. Avoid free text where a value will do, so a script can read it.
How to roll it out
- Pick one agent already in production and write its manifest from what it actually calls, using a month of logs.
- Remove entries nobody can justify. Ask the owner for the reason field on each one.
- Require a pull request, with the agent's sponsor as reviewer, for any change.
- Add a check that compares the manifest with the live tool list and alerts on extra tools.
- Repeat for the next agent. Reuse the same field set so reviews stay quick.
What the manifest does not do
A file describes intent. Enforcement still has to happen where the tool call is made, such as the client, a proxy or the downstream service. OWASP calls this complete mediation: authorization should be enforced in downstream systems, not left to the model to decide. The manifest is the policy, not the lock.
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
Should every agent have its own manifest?
Yes. Separate files keep owners, scopes and review dates distinct, and a change to one agent never alters another.
Does a manifest replace logging?
No. The manifest says what is allowed, and logs show what happened. You need both to answer an audit question.
Sources
Last reviewed: 19 October 2026.
