How to write an MCP server security policy for your organization

Why MCP servers need their own policy track

When an engineer installs an npm package, the blast radius of a vulnerability is broadly contained: the package runs in a sandboxed Node.js process, with access to whatever the process user can access. When an engineer installs an MCP server, the blast radius is fundamentally different. The MCP server becomes a tool the LLM can invoke autonomously — it can read files, call APIs, execute database queries, and in some configurations, spawn subprocesses. A single prompt-injection vulnerability in an MCP server you adopt can turn your LLM agent into a credential exfiltrator.

Standard software procurement processes miss this because they evaluate the software's direct capabilities, not what those capabilities look like when mediated by a language model. An MCP server that technically only reads from a Postgres database is dangerous if it doesn't parameterize queries, because the LLM can be induced to supply a malformed query string that achieves SQL injection. Your security team's questionnaire doesn't ask "does this server parameterize all database queries?" — but it should.

A purpose-built MCP server security policy plugs this gap. It defines the assessment process, the grade floor, the CI gate that enforces it, the exception workflow, and the re-audit schedule.

Policy scope and ownership

Grade thresholds by environment

Every MCP server adopted by [Organization Name] must have a current SkillAudit report no older than 90 days. The minimum grade required depends on the environment and the sensitivity of data the agent can access.

The MCP server registry

The CI enforcement gate

Checking grades manually before every deploy is not sustainable. The grade check must be automated. Here is the reference GitHub Action that enforces the grade threshold at deploy time:

# .github/workflows/mcp-grade-gate.yml
name: MCP server grade gate

on:
  pull_request:
    paths:
      - '.mcp/**'
      - 'mcp.json'
      - 'claude_desktop_config.json'

jobs:
  grade-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Check MCP server grades
        env:
          SKILLAUDIT_API_KEY: ${{ secrets.SKILLAUDIT_API_KEY }}
          MIN_GRADE: ${{ vars.MCP_MIN_GRADE || 'B' }}
        run: |
          # Parse MCP server list from config
          servers=$(jq -r '.mcpServers | to_entries[] | .value.url // .value.command' mcp.json 2>/dev/null || echo "")

          for server in $servers; do
            result=$(curl -sf "https://skillaudit.dev/api/grade?server=${server}" \
              -H "Authorization: Bearer $SKILLAUDIT_API_KEY")

            grade=$(echo "$result" | jq -r '.overall_grade')
            min_sub=$(echo "$result" | jq -r '[.sub_scores[]] | min')

            echo "Server: $server  Overall: $grade  Min sub-score: $min_sub"

            # Block if overall grade is below threshold or any sub-score is F
            if [[ "$grade" < "$MIN_GRADE" ]] || [[ "$min_sub" == "F" ]]; then
              echo "::error::$server does not meet grade requirement (got $grade, min sub $min_sub)"
              exit 1
            fi
          done

          echo "All MCP servers meet grade requirements."

The MIN_GRADE variable is set per-environment in your GitHub repository variables. You set B for production deployments and C for development branches. The gate fails the PR if any server falls below the threshold or if any sub-score is an F — the audit trail and compliance implications of allowing an F-sub-score into production are too high to make it a warning.

The vendor assessment process for new adoptions

The exception workflow

Sometimes a team needs a server that doesn't meet the grade threshold. The exception process exists to make this a deliberate, documented, time-bounded decision — not a handshake in Slack.

Re-audit triggers

The 90-day calendar reminder handles routine re-audits. Four additional triggers require an immediate re-audit regardless of when the last audit ran:

• Server version bump — any version update to a pinned MCP server requires a new audit before the update can be promoted to production. Minor versions can introduce new tool definitions with new permission requirements.
• CVE disclosure — if a CVE is published against a dependency of an adopted MCP server, run a fresh audit the same day. SkillAudit checks advisory databases at scan time.
• Incident involving the server — any security incident where the server was in the tool chain, whether or not it was the direct cause, triggers a re-audit as part of the incident response process.
• Scope change — if the server gains new capabilities (new tool definitions, new permission claims, new upstream API access), treat it as a new server and run the full adoption checklist.

Internal MCP servers

Internally developed MCP servers are not exempt from this policy. They must:

• Be audited before any production deployment using SkillAudit's private repo scan (available on the Pro plan).
• Be re-audited on the same 90-day cadence as external servers.
• Have an assigned owner team in the registry — internal servers without a clear owner drift toward abandonment, which is itself a finding (the Maintenance axis in SkillAudit grades maintenance signals including ownership continuity).
• Follow the same sub-score floors as external servers. The fact that you wrote the code does not mean you wrote it without SSRF vulnerabilities — internal servers consistently show similar finding rates to community servers in SkillAudit's scan data.

Incident response integration

Your incident response runbook should explicitly name MCP servers as a possible actor in any LLM agent incident. When an incident is declared involving an agent, the first diagnostic step is to pull the audit reports for all MCP servers in the agent's tool chain. This immediately scopes whether a known finding could explain the observed behaviour — before you spend hours debugging the LLM prompt.

SkillAudit's Team plan exports the full registry and audit history as a structured JSON — useful for feeding into your SIEM or for evidence requests during incident review. If your incident response process requires producing a timeline of which servers were active in which agents during the incident window, the registry's audit_date and environments_approved fields are the starting point for that reconstruction.

Using this template

This is a starting point, not a finished document. Adapt it to your organization's:

• Existing approval chains — if you already have a software procurement committee, MCP server approvals should route through the same committee with an additional security step, not bypass it.
• Compliance obligations — if you're SOC 2 Type II, the registry and exception artifacts are evidence for CC6.1 (logical access controls). Make sure your auditor knows these records exist. See the full compliance guide for what additional fields your audit logs need.
• Team size — a 5-person startup doesn't need a CTO sign-off on exceptions. A 500-person company probably does. Right-size the approval chain to your organization's risk tolerance and speed requirements.

The SkillAudit Team plan includes policy export (a structured JSON of your registry and all audit reports) and a minimum-grade CI webhook that handles the enforcement gate described in Section 3. If you'd like to see a demo of how the policy integrates with your CI pipeline, start a free audit and the team plan trial includes a 30-minute onboarding session.

The full policy template

Below is a condensed version of the policy sections above, formatted as a document you can drop into your internal wiki. Replace the bracketed fields with your organization's specifics.

MCP Server Security Policy v1.0
Owner: Head of Security
Last reviewed: [DATE]
Next review due: [DATE + 90 DAYS]

1. SCOPE
All MCP servers installed in any LLM agent in any [Organization] environment.
Excludes: demo environments explicitly tagged as out-of-scope in infrastructure catalog.

2. GRADE THRESHOLDS
- Production (PII/financial): A minimum, no F sub-scores
- Production (internal, no PII): B minimum, no F sub-scores
- Staging: B minimum (if mirrors production data)
- Development: C minimum, manager approval required
- CI (ephemeral creds): C minimum

3. ADOPTION CHECKLIST
1. Run SkillAudit scan; record permalink.
2. Verify overall grade and each sub-score meets threshold.
3. Confirm pinned version (no @latest in prod).
4. Document data access scope in one plain-English sentence.
5. Set 85-day re-audit reminder.
6. Add to registry; open PR.

4. EXCEPTIONS
Required: business justification + risk analysis + compensating controls
Expiry: 60 days
Approval: manager + Head of Security; add CTO for prod-PII environments.
Storage: exception_id in registry linked to approval artifact.

5. RE-AUDIT TRIGGERS (immediate, in addition to 90-day cadence)
- Server version bump
- CVE disclosure against a dependency
- Security incident involving the server
- New tool definitions or permission claims

6. INTERNAL SERVERS
Same grade thresholds and re-audit cadence as external servers.
Must have an assigned owner team in the registry.