Skip to main content
Model Context Protocol expands what agents can reach — tools, databases, APIs, filesystems, external services. That expansion makes MCP configuration part of the repo’s security boundary, not a side detail. Misconfigured MCP is not a developer experience issue; it is a supply-chain and access control issue. Charter’s MCP model asks three practical questions on every scan, all answerable from static config alone — no network calls, no runtime observation required.

​
The three questions

Is the server pinned?

Supply chain integrityA floating reference installs a different package tomorrow than it installed today. Charter checks every MCP server reference for a pinned, reviewable version.Rule: AE-MCP-001

Is the remote trusted?

Shadow server riskAn agent should not be pointed at arbitrary remote infrastructure without review. Charter compares remote origins against an effective allowlist of trusted hosts.Rule: AE-MCP-002

Is auth declared?

Unauthorized access preventionA public remote with no declared authentication boundary is an open door. Charter checks for the presence of auth metadata on non-local remotes.Rule: AE-MCP-003

​
Why pinning matters

Floating MCP server references hand version control to the registry’s publish cadence. Examples of risky references:
Three things can go wrong with a floating reference:
  • An agent tool installs a different package version on Tuesday than it installed on Monday
  • A package can be deprecated or archived after a repo first passed Charter
  • A previously-clean pinned version can later become the subject of a CVE or GHSA advisory
Charter’s catalog is aware of deprecated packages. @modelcontextprotocol/server-github was archived — Charter flags it as High with the migration path to github/github-mcp-server. You do not need to know the successor; Charter tells you.

​
AE-MCP-001 finding ladder

For a given server, Charter follows a precedence ladder and reports one finding — the most important next action: The split is deliberate. Charter warns about freshness as an informational signal, but only deducts points when the issue carries a real maintenance or security risk.

​
Why trusted remotes matter

AE-MCP-002 maps to OWASP MCP09: shadow MCP servers. A coding agent should not be pointed at arbitrary remote infrastructure without review. In practice, Charter treats this as two layers:
  • Local and internal origins are exempt — no allowlist check required
  • Public remote hosts are compared against the effective allowlist: charter.yaml mcp.trustedRemotes + catalog trustedHosts
Unknown public origins are flagged as High severity. The per-repo trustedRemotes list in charter.yaml is how teams document reviewed exceptions beyond the vendor baseline.

​
Why auth declaration matters

AE-MCP-003 maps to OWASP MCP07: insufficient authentication and authorization. Charter’s check is intentionally presence-based — it does not attempt to validate credentials or enforce a specific OAuth flow. It only asks whether the config declares an auth header such as:
  • Authorization
  • X-Api-Key
  • Api-Key
  • X-Auth-Token
That keeps the rule resilient as MCP transport and authentication details evolve, while still catching the unsafe case of a public remote with no declared auth boundary. Catalog-known OAuth vendor hosts are exempt because they authenticate through the OAuth flow rather than a static config header.

​
OWASP MCP Top 10 coverage

Floating and deprecated package references allow supply-chain substitution without review. AE-MCP-001 requires exact pinning and flags deprecated packages with their known successors.Severity when triggered: High (unpinned, deprecated, or advisory-affected) or Informational (behind stable, no advisory)
Remote MCP servers without declared authentication metadata create open access surfaces. AE-MCP-003 requires auth header declaration for all non-local, non-OAuth-vendor remotes.Severity when triggered: High
Unreviewed public remote infrastructure gives agents tool access that was never explicitly sanctioned. AE-MCP-002 compares remote origins against a maintained allowlist and flags unknowns.Severity when triggered: High

​
How the catalog works

Charter ships an embedded MCP catalog so the scanner stays offline and deterministic. The catalog provides:
  • known server package metadata and stable versions
  • deprecated package successors and migration paths
  • known advisories and their fixedIn versions
  • a trusted-host baseline for major vendor-operated remote endpoints
Two design choices keep the catalog honest: Exact-match version logic. The catalog does not try to compare arbitrary version strings across semver, CalVer, or custom schemes. Charter only makes strong claims when it has exact knowledge of the version in use. A stale catalog under-reports rather than misreports — conservative by design. One finding per server. For a given server, AE-MCP-001 reports the single most important signal following the precedence ladder: deprecated → unpinned → advisory → behind-stable → clean. Output stays focused on the most important next action.

​
Next steps

Investigate MCP Findings

The step-by-step recipe for resolving each of the three MCP rules.

charter.yaml Reference

Declare reviewed remote hosts with mcp.trustedRemotes.

Fix Engine

How the AE-MCP-001 fixer applies catalog-aware version bumps.

Rules Reference

Full detail on AE-MCP-001, AE-MCP-002, and AE-MCP-003.