Policy Before Plugins — Write the MCP Allowlist Before You Install Another Server

The Influzer directory now lists well over 10,000 MCP servers. Only a few percent expose indexed tools. Your agent does not need the next listing this week.

It needs a one-page answer to three questions — what may connect, what may write, and what is banned — before anyone pastes another npx line or clicks Connect in Claude.

That sequencing is the whole article. Policy before plugins.

This week made the cost of the reverse order obvious. Engineers are publishing pre-execution policy gates for MCP tool calls. Security write-ups are treating coding agents as an incident surface, not a toy. Azure shipped a remote MCP server to GA without Claude, ChatGPT, or Cursor support — a reminder that “there is a plugin” is not the same as “your team can safely use it.”

None of that is a reason to freeze MCP. It is a reason to stop treating install as the first step.

The wrong order (how most teams actually work)

Here is the default loop we see in Cursor, Claude, and ChatGPT setups:

1. Someone finds a server in a directory, a tweet, or an npx gist
2. They install it in a personal config “just to try”
3. It works once, so it stays
4. A teammate copies the snippet
5. Six weeks later it is in a shared .cursor/mcp.json with a write tool nobody reviewed
6. Security hears about MCP when something already happened

That is not a tooling problem. It is a sequencing problem. The catalog made discovery cheap. Install UX made connection cheap. Policy is still a Google Doc that does not exist.

We already argued that most MCP servers are still demoware and that .cursor/mcp.json is becoming team policy. This post is the missing prerequisite: do not add the next server until the allowlist exists — even an ugly one-pager beats another unreviewed plugin.

What “plugin” means in MCP (it is not just a Chrome extension)

In this ecosystem a plugin is any capability you attach to an agent:

• A local stdio server via npx / Docker in Cursor or Claude Code
• A remote HTTPS MCP connector in Claude, ChatGPT, or a gateway
• A Slack / Tag connector that can call tools from a channel
• A vendor “MCP server” checkbox in a SaaS admin panel

They all grant tools. Tools are production access with a friendlier name. If your mental model is “it’s just a helper,” you will approve Class C/D writes the way people used to approve “temporary” production SSH keys.

Leaders: map this onto decision classes in tool access as an operating control. Builders: assume every new server is a dependency review, not a theme park ride.

The one-page allowlist (steal this)

If you write nothing else this week, write this table. Pin it in Slack. Put it above the shared MCP config. Reject PRs that violate it.

Three rules that make the table real:

1. Default deny for write tools. Read is the on-ramp. Write is an exception with a name next to it.
2. Two lists, not one. Local stdio and remote HTTPS are different products — see remote vs local. A Cursor laptop policy is not a Claude Enterprise policy.
3. No anonymous servers. Every allowed slug has an Influzer (or internal) detail page, an owner, and a date you will re-review it.

Five installs to refuse this week

You do not need a legal team to say no. Use this as a hallway test. If any box is true, the server waits until the allowlist says otherwise.

1. It is not on the list. “We’ll add it to the doc later” is how later never happens. PR the allowlist first, then the config.
2. Transport is a shrug. Unknown, “clone it and see,” or sold as remote when it is localhost-only. Azure’s GA remote MCP that does not speak your client is the same failure mode: a plugin that cannot actually run where your agents live.
3. Zero honest tools. If tools/list is empty, toy, or a dump of undocumented endpoints, it fails the 30-second demoware filter. Discovery is not approval.
4. Auth is a personal PAT in git — or a token stuffed into a header that proxies will log. See don’t put secrets in MCP headers.
5. It can mutate money, access, customer data, or production and nobody can name who gets paged when it does it wrong.

If you want the longer diligence path, run the seven-question audit after the hallway test — not instead of it.

Policy is not a gateway product (yet)

The interesting engineering this week is people building pre-execution gates: intercept the tool call, check a policy, then allow or deny. That is the right long-term shape — the same instinct as admission control for Kubernetes or a WAF for HTTP.

Most teams are not ready to build that. They are ready to do something more boring and more valuable:

• Publish the allowlist
• Put it in git next to .cursor/mcp.json
• Require a reviewer on MCP config diffs
• Ban arbitrary npx in shared configs
• Keep a read-only discovery server so agents can search without installing

That last one is the pressure valve. Connect Influzer MCP Discovery so the agent can look up capabilities. Humans still decide whether a found server earns a slot. Search is Class A. Install is Class C until proven otherwise.

When you do grow into runtime gates, start with write tools and high-impact names (delete_*, refund, grant_access). Do not boil the ocean by wrapping search_docs.

A 48-hour rollout that actually ships

Do not start a working group. Do this:

Hour 0–2 — inventory, not architecture

Export what is already connected: project .cursor/mcp.json files, Claude connectors, ChatGPT custom connectors, Slack tools. Paste them into a spreadsheet. Mark each: read / write / unknown. Unknown counts as write until proven.

Hour 2–4 — write v0 of the table above

Ugly is fine. Three rows. Named owner at the bottom. Default deny for writes. Publish it in the same PR as the first committed allowlist comment in the repo README.

Hour 4–8 — shrink, don’t add

Remove one server that fails the hallway test. Pin versions on what remains. Move secrets to env. Add Discovery as the safe default if it is missing.

Day 2 — make the policy load-bearing

Add a PR template checkbox: MCP config change — allowlist updated if new server or write tool. Tell the team in Slack: new installs go through the table, not DMs. Schedule a 30-day re-review. Stop.

That is enough to change the default from “install then maybe govern” to “govern then maybe install.”

How this fits the rest of the Influzer stack

• Quality filter — is this server real? → Demoware in 30 seconds
• Repo perimeter — where does the allowlist live in Cursor? → .cursor/mcp.json as team policy
• Executive control — liability, IdP, evidence → Tool access as an operating control
• Auth growing up — paste-a-key to IdP → Enterprise-managed MCP auth
• Finding without installing — → Discovery as App Store search

Policy before plugins is the order of operations. The other posts are how to execute each layer without turning it into a novel.

Quick answers

Can we keep experimenting locally?

Yes. Personal / global config is the sandbox. Shared repo config and org connectors are production. The allowlist is about what ships with the team, not what you run on a throwaway branch.

Isn’t an allowlist just bureaucracy?

Bureaucracy is a 40-page standard nobody reads. A one-page table that blocks mystery npx is closer to package.json than to ISO paperwork.

What if a vendor MCP does not support our client?

Then it is not a plugin for your team yet. GA on one surface (VS Code, Copilot, a custom host) does not entitle it to Cursor or Claude. Wait, wrap, or use a client that actually speaks it — do not pretend Connect will invent compatibility.

Should we ban MCP until legal signs off?

Ban unmanaged MCP. A total ban usually creates shadow configs. Approved list + default-deny writes + Discovery for search is the adult path.

Where do we look first for candidates?

The Top 100 (tools-first, not star-count), then Discovery from inside the agent, then the hallway test. Submit anything we are missing at /mcp/submit.

Related reading

• Most MCP servers are still demoware
• .cursor/mcp.json is becoming team policy
• AI agent tool access as an operating control
• Seven-question MCP server audit
• Brief: remote vs local is the real split

Final thought

The catalog will keep growing. Clients will keep adding a Connect button. Someone on your team will find a dazzling demo on a Friday afternoon.

Plugins without a policy are not velocity. They are unreviewed production access with a friendly install UX.

Write the one-page allowlist first. Then install the two or three servers that survive it. Let Discovery search the rest. Everything else can wait — including the next shiny listing.

Start from the Top 100. Wire Discovery. And when the next plugin looks shiny, ask the only question that matters this week: is it already on the list?