What is a Server-Level Policy?

When an MCP server exposes dozens or hundreds of tools, writing individual tool-level policies for each one is impractical. Server-level policies solve this by defining sensible defaults: "deny all tools on the production database server" or "log all tools on the Stripe server." These defaults apply to every tool unless explicitly overridden.

This default-then-override pattern is the standard approach in access control systems. AWS IAM, Kubernetes RBAC, and firewall rules all work the same way: set a broad default, then create specific exceptions. It scales because you only need to write rules for the exceptions — the default handles everything else.

Server-level policies are particularly valuable for risk management. A new MCP server added to your stack is immediately governed by its server-level policy, even before you have reviewed its individual tools. If your server-level default is deny, new tools are blocked automatically. This prevents the common failure mode where a server update adds new capabilities that the agent exploits before policies catch up.

In Intercept, each policy file targets a specific MCP server and can define a default action that applies to all tools on that server. Tool-level rules within the same file override this default. Server-level policies also support conditions — for example, you can log all tool calls on a server during off-hours while allowing them normally during business hours. The server-level default is evaluated last, after all tool-level rules have been checked.