MCP Governance Risk Audit

MCP Governance and Risk Audit

Audit the organization serving the MCP server. Answer: Is this MCP server ready to be exposed in the stated environment, and under what launch controls?

Do not turn the assessment into a consumer-side catalog review. The host and expected clients matter only where their behavior changes the provider's protocol, authorization, consent, or threat model.

Safety and scope

• Default to a read-only audit. Do not edit the target, invoke write-capable tools, probe a live endpoint, create accounts, or alter cloud resources without separate authorization.
• Follow repository instructions before inspecting implementation evidence.
• Treat secrets, client data, tenant identifiers, internal endpoints, and raw audit samples as sensitive. Redact them from the report.
• Keep private evidence out of public artifacts.
• State that this is a technical risk assessment, not a certification or legal opinion.

Load the relevant references

Always read:

• references/audit-method.md
• references/report-template.md

Read these when assessing any implementation or technical plan:

• references/mcp-specification.md
• references/authorization-and-registration.md
• references/provider-security-controls.md

Read references/source-index.md when validating currency, resolving ambiguity, or citing the basis for a finding.

Audit workflow

1. Establish the target and audit mode

Record:

• Server name, owner, business purpose, intended users, and intended launch environment
• Audit mode: implementation, roadmap, or mixed
• Target MCP protocol version or versions
• Transport and endpoint model: STDIO, Streamable HTTP, legacy HTTP+SSE, or custom
• Public, partner, internal, local, or multi-tenant exposure
• Tools, resources, prompts, and server-requested client features
• Downstream systems, data classes, user identities, service identities, and authorization server
• Whether the endpoint is pre-production or production

If a roadmap omits the protocol version, evaluate new work against the latest stable MCP revision in the bundled snapshot and flag the missing version decision. If network access is available, check the official MCP specification first and record the version and access date. Do not silently audit against a draft.

2. Build an evidence ledger

Inspect the smallest relevant set of source, configuration, tests, deployment definitions, diagrams, and runtime artifacts. Label every conclusion:

• Verified: directly supported by implementation, configuration, test, or authorized runtime evidence
• Planned: specified in an actionable roadmap or design, but not implemented
• Claimed: asserted in prose or conversation without adequate proof
• Missing: required evidence or control is absent
• Not applicable: demonstrably outside the assessed scope

Never promote Planned or Claimed to Verified. A roadmap audit can conclude that a design is ready to implement, but cannot conclude that a production control works.

3. Inventory and classify the serving surface

Inventory every exposed tool, resource, prompt, completion path, extension, compatibility endpoint, and server-requested client feature. For each, record:

• Input and output schema
• Data read or returned
• Side effects and downstream authority
• User or service identity used
• Required scopes or permissions
• Human approval behavior
• Failure and rollback behavior
• Rate, size, time, and concurrency limits

Count the effective surface, not only the names returned directly by tools/list. Follow meta-tools, routers, generic call_tool methods, action enums, plug-in registries, and feature flags to every operation they can reveal or invoke. Apply discovery filtering, authorization, approval, logging, and tiering to the underlying operation as well as the dispatcher.

Classify the entire server by its highest-risk exposed capability. Do not average away an administrative tool because most tools are read-only.

4. Audit MCP conformance by declared version

Use references/mcp-specification.md. Separate:

• Normative protocol failures against the version the server claims to implement
• Interoperability risks
• Deprecated features and migration debt
• Optional features that are simply not implemented

For a new public launch, also assess the migration path to the latest stable revision. Do not require 2026-07-28 wire behavior from a server that explicitly and correctly serves 2025-11-25, but do flag an unsupported or accidental version story.

5. Audit authorization and client registration

Use references/authorization-and-registration.md. Keep the roles separate:

• The MCP server is normally the OAuth protected resource.
• The authorization server issues tokens and implements client registration.
• The MCP client is the OAuth client.
• One deployment may operate more than one role, but the audit must not conflate them.

Explicitly determine which registration path is supported: pre-registration, Client ID Metadata Documents (CIMD), Dynamic Client Registration (DCR), or manual registration. For the 2026-07-28 MCP revision, CIMD is the preferred path and DCR is deprecated but retained as a compatibility fallback.

Provider accountability includes the authorization server integration even when it is a managed dependency. Verify discovery, redirect validation, resource and audience binding, token validation, scope enforcement, error challenges, client trust policy, and protection of any metadata-fetching path.

Trace token validation to the cryptographic verification call. A guard that trusts a decoded request identity does not prove issuer, audience, expiry, token type, or scope validation upstream.

6. Apply provider-side OWASP controls

Use references/provider-security-controls.md. Evaluate hard gates before risk scoring. A failed hard gate cannot be repaired by a low numeric score.

Apply the OWASP governance principles from the provider's perspective:

1. No served MCP without a named owner.
2. Classify the server before launch.
3. Give each tool only the downstream authority it needs.
4. Make human approval meaningful for consequential actions.
5. Produce attributable, redacted production audit evidence.
6. Provide a maintained, supportable launch path that discourages shadow endpoints.

Also cover the OWASP MCP Top 10 and secure server development controls without claiming that every OWASP recommendation is a normative MCP requirement.

7. Test claims proportionately

Prefer existing tests and safe local test harnesses. For implementation audits, look for negative evidence such as:

• Unsupported protocol versions and missing required metadata are rejected correctly
• Undeclared capabilities are not used
• Invalid schemas, unknown tools, path traversal, command injection, oversized inputs, and malformed JSON-RPC fail closed
• Missing, expired, wrong-issuer, wrong-audience, and under-scoped tokens are rejected
• Client tokens are not forwarded to downstream APIs
• DCR or CIMD redirect and metadata validation resist SSRF and open redirects
• Tenant and user state cannot cross request boundaries
• Denied human approval prevents the action
• Logs prove who invoked which operation and outcome without recording secrets
• Invalid present Origins receive HTTP 403 rather than merely losing CORS response headers
• Meta-tools cannot enumerate or invoke an underlying operation the caller is not authorized to use
• Rate limits, timeouts, cancellation, and downstream failures preserve safe behavior

Do not claim runtime verification when only static evidence was available.

8. Decide and report

Use exactly one decision:

• Ready: all applicable hard gates pass and launch controls are verified
• Conditionally ready: no hard gate fails, but explicit pre-launch conditions remain
• Pilot only: limited non-production use is supportable, but production evidence or controls are incomplete
• Not ready: at least one hard gate fails or the current design creates unacceptable exposure
• Insufficient evidence: the available material cannot support a defensible decision

For roadmap-only reviews, prefix the decision with Design, such as Design conditionally ready, and state that implementation effectiveness remains unverified.

Each finding must include:

• Severity: Blocker, High, Medium, or Low
• Evidence status and precise evidence pointer
• Affected surface and scenario
• Requirement source: MCP normative requirement, OWASP hard gate, OWASP risk control, or local policy assumption
• Impact in concrete provider terms
• Smallest useful remediation
• Verification needed to close it

Use the report structure in references/report-template.md. Cite primary sources for protocol claims. Credit the OWASP MCP Governance and Risk Project when using its framework.