Skip to content
PERMISSION/PROTOCOL

MCP Guard · Open source

MCP authorization for your agent’s tool calls.

MCP Guard is an open-source stdio MCP proxy. Check routed tool calls against your policy before they reach the server: allow, block, or hold for approval.

Review setup Walk through an approval

What you are connecting

Your MCP client → MCP Guard → your stdio MCP server.

Start on a test server, review the decision log, then enable the rules you need.

Policy preview
Example actiondeploy_production

  1. Tool call requested

    The client routes the call through the proxy.

  2. Policy requires approval

    A require_approval rule matches this tool.

  3. Hold returned

    Enforce mode returns a hold error to the client.

  4. Call not forwarded

    The stdio server does not receive this call.
Tool call requested
Illustrative enforce-mode flow. No actions are sent.

The protected path

MCP server access and tool-call approval

MCP authorization can refer to access tokens for an HTTP server. MCP Guard works on configured stdio routes, where it checks the requested tool name before the call reaches the server. Keep the server’s credential controls and add rules for the actions that need review.

Choose the calls that need a decision

For example, your policy can allow a read, block a destructive tool, and hold a production deployment. In enforce mode, a blocked or held call returns an error and never reaches the server. If the optional approval UI is running, a held call instead waits, with no timeout, until someone approves or denies it. Test each outcome on your own tool path.

Read the MCP policy enforcement guide

From setup to a tested decision

Connect one workflow, then verify it.

  1. Choose the server path

    Use a stdio MCP server you can launch through the proxy. Update the client configuration so calls use that path.

  2. Define and observe the rules

    Match exact tool names to allow, block, or require approval. Observe mode logs each decision while forwarding every call.

  3. Test enforcement

    Switch to enforce mode and test allowed, blocked, and held calls. Without the optional approval UI, a held call returns an error and does not reach the server.

# Log each decision but forward every call (observe mode):npx -y @permission-protocol/[email protected] --config pp.config.yaml --mode observe -- node my-mcp-server.js# After reviewing the decisions, enforce the rules:npx -y @permission-protocol/[email protected] --config pp.config.yaml --mode enforce -- node my-mcp-server.js

Validated against @permission-protocol/mcp-guard 0.1.0 on October 14, 2026. Replace the example server command and tool names with your own.

Read the source on GitHub

Scope and boundaries

What this controls, and what it doesn’t.

  • Only calls routed through the proxy are evaluated. Direct credentials and other tool paths remain outside it.
  • Observe mode does not block. Without the optional local approval UI, a require-approval rule returns a hold error. That UI in 0.1.0 has no sign-in, listens on all network interfaces, and accepts requests from any web page, so use it only to evaluate test tools.
  • Local JSONL decision records include payload hashes. A hash alone is not a cryptographic signature or independent proof of human authorization.
  • Confirm the transport, package version, record fields, and signing requirements for your deployment.

The record behind the decision

Decide what evidence you need.

MCP Guard 0.1.0 writes an unsigned local decision log and does not record who approved a held call. If your reviewers need signed human-approval evidence, discuss your workflow before rollout.

What a signed receipt records Discuss your workflow
How to choose which AI actions need human approval

Your first workflow

Ready to test your first workflow?

Work through setup, approval, denial, and evidence inspection. Keep track of your checks before expanding the rollout.

Open the test checklist