Constrain the arguments of each tool call, not just which tools are allowed. Check file paths against an allowed folder, recipients against an approved list, record IDs against the caller's own data, and amounts against a cap. Enforce the checks in code outside the model, because the model can be talked into anything.
Why tool level allow lists fall short
An allowed "send email" tool can still email anyone. An allowed "read file" tool can still read a secrets file. The tool is permitted, but the call is dangerous. Argument limits close that gap.
The MCP specification says servers must validate all tool inputs and implement access controls, and that clients should show tool inputs to the user before calling the server to avoid malicious or accidental data exfiltration. Both point at the arguments, not just the tool name.
Argument limits by argument type
| Argument | Risky default | Safer limit |
|---|---|---|
| File path | Any path on the host | One project folder, resolved to a real path before checking |
| URL to fetch | Any address | Approved domains, no internal addresses |
| Email recipient | Anyone | Company domain or approved list |
| Record ID | Any record | Records the requesting user can already see |
| Amount or quantity | Unbounded | A per call and per day cap |
| Free text query | Raw string to a database | Parameterised, length limited |
Steps to add argument checks
- For each write, delete or send tool, name the one argument that decides how bad a call can be.
- Write the rule as a plain sentence, such as "recipient domain must be on the approved list".
- Implement it in the server or a proxy in front of it, before the downstream call runs.
- Return a clear error when a call is blocked, so the failure shows up in logs and the agent can recover.
- Test with hostile input: path tricks, a lookalike domain, an amount just over the cap.
- Log the blocked attempts. A spike is an early warning.
Common mistakes
Checking the string, not the resolved target, lets path tricks through. Allowing a whole domain family when you meant one host is another. Putting the rule in the prompt ("never email outsiders") is guidance, not a control. OWASP's guidance is direct: enforce authorization downstream and do not let the model decide what is allowed.
When a human should decide
If a rule is hard to express, such as "is this refund reasonable", send the call to a person with the arguments displayed. Approval fits judgment calls, and argument limits fit rules.
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
Can I put the argument rule in the system prompt?
Not as your only control. A prompt can be overridden by injected text, so enforce limits in code at the tool or proxy.
Where should the check run?
At the server or a proxy in front of the downstream call, and ideally again in the downstream system.
Sources
- Model Context Protocol specification, Tools, Security Considerations
- OWASP LLM06:2025 Excessive Agency
Last reviewed: 19 October 2026.
