Security Policies

Security policies control which MCP servers are allowed to run on your machine or in your organization. They act as guardrails that enforce minimum trust requirements before any code is executed.

Overview

Policies are configured in ~/.mcp/config.yaml under the policy section. Three independent checks are evaluated before every smcp run:

1. Origin policy – Is the publisher type allowed?
2. Certification level policy – Does the package meet the minimum certification tier?
3. Score policy – Does the package meet the minimum security score?

All three checks must pass for execution to proceed (when in strict mode).

Origin Policy

Control which publisher types are allowed to run on your system:

Configuration

policy:
  allowed_origins:
    - official
    - verified

The example above blocks all community MCPs from running. Only packages from official and verified publishers are permitted.

Behavior

• If a package’s origin is not in the allowed_origins list, execution is blocked (in strict mode) or a warning is shown (in warn mode).
• An empty list means no packages can run.
• Including all three origins allows everything.

Certification Level Policy

Set a minimum certification level to enforce a baseline of security analysis:

policy:
  min_cert_level: 2  # Only Security Certified or higher

See Certification Levels for a detailed explanation of each tier.

Enforcement Modes

The cert_mode setting controls how certification level violations are handled:

policy:
  cert_mode: "strict"

Score Policy

Set a minimum security score threshold:

policy:
  min_score: 70  # Reject anything scored below 70 out of 100

When a package’s security score is below the threshold:

• In strict mode, execution is blocked with exit code 4.
• In warn mode, a warning is displayed and the user is prompted to confirm.
• The --trust flag bypasses the interactive prompt (but not strict mode blocking).
• When --trust is used, smcp injects security warnings into the MCP protocol for LLM awareness. See LLM Security Warnings.

See Security Scores for how scores are computed.

Combining Policies

All policies are evaluated together as a logical AND. Every check must pass for execution to be allowed:

origin check AND cert_level check AND score check = ALLOW

If any single check fails in strict mode, execution is blocked.

Example Configurations

Production (Strict)

Lock down execution to only well-vetted packages:

policy:
  min_cert_level: 2
  min_score: 80
  allowed_origins:
    - official
    - verified
  cert_mode: "strict"

This configuration:

• Requires Security Certified (Level 2) or higher
• Requires a score of at least 80/100
• Blocks community packages entirely
• Hard-blocks any violation (no prompts, no overrides)

Development (Permissive)

Allow experimentation with warnings for risky packages:

policy:
  min_cert_level: 0
  min_score: 0
  allowed_origins:
    - official
    - verified
    - community
  cert_mode: "warn"

This configuration:

• Accepts any certification level
• Accepts any security score
• Allows all origin types
• Shows warnings for low-scoring packages but does not block them

Team Standard

A balanced approach for team environments:

policy:
  min_cert_level: 1
  min_score: 60
  allowed_origins:
    - official
    - verified
    - community
  cert_mode: "strict"

This configuration:

• Requires at least Static Verified (Level 1)
• Requires a minimum score of 60/100
• Allows all origin types (but score/cert gates still apply)
• Enforces strictly with no override