Yes. Allow more tools in development, fewer in staging and only the proven minimum in production. Use separate allowlists and separate agent identities per environment, and promote a tool upward only after review. One shared list forces you to choose between blocking developers and exposing production.
Why one list fails
If the allowlist is tight enough for production, developers cannot experiment and will route around it with personal setups. If it is loose enough for developers, production agents inherit tools they should never hold. Splitting by environment removes the trade off.
What to allow where
| Tool type | Dev | Staging | Production |
|---|---|---|---|
| Read only lookups on test data | Yes | Yes | Only if needed |
| Read on real data | No | Limited | Only if needed, scoped |
| Write or delete on test systems | Yes | Yes | Not applicable |
| Write or delete on real systems | No | Approval gated | Approval gated, narrowest |
| Shell, arbitrary URL fetch, code execution | Sandboxed | Sandboxed, reviewed | Avoid |
| New or unreviewed servers | Allowed with logging | No | No |
OWASP's excessive agency guidance supports the production column. It says to limit extensions to the minimum necessary, avoid open-ended ones such as running a shell command or fetching any URL, and prefer granular tools.
Steps to set it up
- Create one allowlist per environment, stored in version control with required reviewers.
- Give each environment its own agent identity and its own credentials. A dev token must not work in production.
- Keep real data out of dev. If a dev agent can read production data, the environment split is cosmetic.
- Define a promotion path: a tool moves from dev to staging after a security look at its server, scopes and logging, and from staging to production after a trial with real traffic patterns and an owner's approval.
- Record the version of each server. The MCP specification lets servers announce changes to their tool list, so a tool that was reviewed last month may not be the same tool today.
- Alert when a production agent sees a tool that is not on its list.
Watch for drift
Allowlists age. Servers add tools, developers add servers to fix a quick problem, and old entries never leave. Schedule a review, remove entries with no calls in the period, and compare the live tool list with the approved one.
Test the boundary
Try calling a dev only tool from a production agent in a safe window. It should be refused by the enforcement point, not by the model's good manners. Repeat after each change.
Keep it simple enough to follow
A three column table that people understand beats a clever policy that nobody can explain. Start there and add detail only where an incident or audit shows a gap.
Try it yourself
Click through it at your own pace, or open it full screen. Note which tools a server exposes, then decide which environments should see each.
Safeguard's MCP Guardrail and policy features are aimed at enforcing this kind of tool control, and a free scan is available at https://gold.safeguard.sh/scan.
Quick check
Can dev and prod share one agent identity?
No. Separate identities and credentials stop a dev token working in production.
How do I know a reviewed tool has not changed?
Record the server version and compare the live tool list with the approved one on a schedule.
Sources
Last reviewed: 19 October 2026.
