Allow-list MCP tools per policy

A registered MCP server advertises whatever tools it wants — and an agent will happily call any of them. The safe posture is the inverse: decide the short list of tools you actually need, allow exactly those, and deny the rest. That’s an allow-list, and on OrcaRouter you build it out of tool_name_glob rules evaluated on the mcp surface. Every tools/call that crosses the MCP gateway is run through your firewall policy before it reaches the real server. So the allow-list isn’t advisory — a call to a tool you didn’t allow never dispatches.

​

1. Why a default-deny allow-list for secure mcp tools

A deny-list — “block the dangerous tools” — fails the moment a server adds a new tool, renames one, or you connect a second server. The set of dangerous tools is open-ended; the set you meant to use is small and known. An allow-list inverts the default so the unknown is refused, not admitted:

• New tools are denied by default. A server that grows a delete_repo tool after you connected it can’t be called until you add it to the allow-list.
• Scope is per server. The <server>.<tool> namespace lets you allow github.create_issue while denying everything else under github.*.
• One choke point. The same policy governs the bundled server and every BYO server behind the gateway, so there’s one place to read the allow-list.

​

2. The two pieces

An allow-list is a default_verdict plus an ordered set of rules. The glob is matched against the namespaced tool name — github.create_issue, shell.exec. * matches any tool (use it sparingly; an allow rule with * un-does the whole allow-list). A leading <server>. scopes the glob to one server.

​

3. One concrete example

You connected a github server and you only want agents to read and open issues — never delete or administer anything. In the console, open Firewall → Policies, set the policy’s default verdict to deny, and add two allow rules: That’s the whole allow-list. With the default at deny:

• github.create_issue → matches rule 1 → allow, dispatches.
• github.delete_repo → matches nothing → deny by default.

A denied MCP call comes back to the model as a tool error (firewall deny: …) — the same shape any failing tool returns — so the agent can adapt rather than crash. (On the inbound surface a deny is instead an HTTP 400 with error code firewall_blocked.)

​

4. Tightening with arguments

A tool name on the allow-list can still be called with bad arguments. Narrow further by adding an args_match clause (JSONPath + an operator like eq, contains, regex, in, or cidr_match) to the rule, or by layering a deny rule above the allow for a specific argument shape — for example, allow github.create_issue but deny it when the target repo isn’t on an approved list. See the firewall rules reference for the full operator set.

​

5. Roll it out safely

Flip a whole-server default-deny in production and you risk breaking an agent that quietly depended on a tool you forgot. Two settings de-risk it: Once the shadow log is clean — no legitimate call would have been denied — clear shadow_mode and the allow-list enforces.

​

6. Verify it works

After enforcing, confirm denied tools actually get refused:

• Dry-run a tools/call against the policy (Developer+) to see the verdict and which rule — or the default — produced it, without sending real traffic. Pass a tool name, surface, and sample args; the engine evaluates them and returns the verdict trace without recording an event.
• Watch the events. Each blocked call records a firewall event a Developer+ can read in the console; the audit events page covers the feed and its fields.

​

Related