MCP approval workflow: fast, defensible reviews for unverified MCP servers

Addressing the problem of shadow MCP is a workflow problem as much as it is a technical problem. Once an unapproved server has been identified, what's the process for making a decision on permitted use in the organization?

Today we're releasing the MCP Approval Flow on the AI Control Plane. The Shadow MCP blocking policy that prevents tool calls to unknown servers, now also opens a review process. The control plane assembles information on the server, and surfaces a decision to the security team. You can then decide exactly who the server is approved for, and all subsequent traffic will adhere to your decision.

How the MCP Approval flow works

Shadow MCP detection and blocking already tell you when an agent reaches an unreviewed server. MCP Risk Approval completes the loop from block to decision:

1. An agent calls a tool on an unreviewed MCP server, and a shadow MCP policy blocks the call. The person who hit the block gets a request link.
2. The link opens a justification form asking why they need the server. No dashboard login required.
3. The request attaches to the server's review page under Secure → Shadow MCP, in the same table as your observed inventory. Servers awaiting a decision sort to the top. The elected reviewers are notified of the pending server.
4. Your security team reviews the evidence and approve or deny, with optional scoping to the requester, a team, or a project.
5. Approval writes the grant on the blocking policy in the same transaction. The requester retries the tool call and it runs.

Approve or deny sits in one drawer with the audience and the rationale, so the decision and its reasoning are recorded together.

What evidence does Speakeasy gather about an MCP server?

Evidence is assembled automatically, with no model in the loop, and organized around the questions you'd ask in a real review:

• Who am I trusting? Publisher, official flag, domain match, registry age, source repository, and license.
• What is it asking us to hand over? OAuth scopes, auth mode, and the secrets and headers the server demands.
• What can it do? Declared capability for every tool, with the tools that act on a user's behalf called out.
• Is it real and maintained? GA versus beta, maintenance recency, and popularity.
• Are we already exposed? Whether the server is already in use in your org, how many people are asking for it, and any findings its traffic has already produced.
• What do we already know? Whether a vendor contract or a prior security review is on file.

When registry metadata isn't enough, you can send a research agent to dig further. It searches independent sources (GitHub issues, security advisories, package and maintainer history, domain age, incident history), not just the vendor's own materials. Its report separates what was observed, what independent sources report, and what the vendor claims, with a citation on every claim. If nobody independent has written about a server, the report says so, because absence of coverage is itself a finding. The agent gathers and cites; it never approves anything.

What happens after you approve?

A daily sweep re-gathers evidence for approved servers and compares the permission-relevant slice (OAuth scopes, auth mode, demanded credentials, and published advisories) against the snapshot your approval rested on. If something changed, the server is flagged as changed since approval, once per distinct change, until a new decision clears the flag.

The sweep is a prompt to look again, not a threat control. A server whose published interface is unchanged but whose behavior isn't will pass any fingerprint comparison, which is one more reason to grant as narrowly as the request allows.

Get started

Reviews live under Secure → Shadow MCP, next to your shadow MCP inventory. Talk to your Speakeasy team to enable MCP Risk Approval for your organization, or book time with our team if you're still reviewing MCP servers in Slack.