Field Note / Tool Risk

MCP Is Not the Whole Problem

MCP matters because it makes tools easier for agents to reach. But focusing only on MCP can hide the broader action path: CI/CD, scripts, credentials, repo automations, package workflows, and release paths.

Last updated: May 9, 2026

MCP is a signal, not the whole boundary

MCP is useful because it gives AI-assisted workflows a more standard way to discover and call tools. That also makes it a useful review surface. Teams should know which MCP servers exist, which tools they expose, which credentials they use, and which calls can change state.

The mistake is treating MCP as the entire security problem. In software delivery, many high-impact action paths do not start or end with MCP.

The other action surfaces

A complete review has to include the delivery artifacts that already carry authority:

MCP can connect to some of these surfaces, but it does not replace them. The action path is the control object.

agent/workflow -> tool or script -> credential -> action -> target -> approval/proof

Why this matters for security review

If the review only asks "which MCP servers are enabled?" it may miss a workflow-file change that exposes secrets, a package script that runs during CI, or a release automation path that inherited broad credentials.

A better review starts with the action classes: read, write, execute, publish, deploy, delete, access secret, change workflow, call cloud API, or write to a system of record. Then it maps which surfaces can produce those actions.

Practical review order

  1. Inventory MCP and tool declarations.
  2. Map CI/CD workflows and package scripts touched by AI-assisted work.
  3. Identify credentials and identities inherited by those workflows.
  4. Classify reachable actions as allowed, approval-required, or blocked.
  5. Confirm proof exists for actor, credential, action, target, approval, validation, and outcome.