PulseFlow Tecnologia
← Insights
·6 min read·framework-playbook·mcp·tool-use·security
PulseFlow Tecnologia

A security playbook for MCP and tool use

Knowing that vulnerabilities exist in MCP is one thing; having an organizational playbook that assigns an owner, a process, and a response to each risk category is another. The MCPSHIELD research mapped "7 threat categories and 23 distinct attack vectors organized across four attack surfaces" by analyzing more than 177,000 registered MCP tools - giving any security team a concrete starting point to organize controls, not just identify them.

Why no single control is enough

MCPSHIELD's most important finding isn't the vulnerability list - it's that no single defense mechanism covers more than 34% of the mapped threat surface. That changes the logic of a security playbook: instead of picking "the best control," the goal is combining complementary controls. The architecture MCPSHIELD itself proposes combines capability-based access control, cryptographic tool attestation, information-flow tracking, and runtime policy enforcement - and even that combination reaches 91% theoretical coverage, not 100%.

Tool registry as a governance artifact, not just a technical one

A central tool registry - listing every approved MCP tool, its scope, its owner, and its last security review - is what turns "authentication" and "authorization" from technical concepts into auditable process. GitHub recommends validating JWT against JWKS and checking token audience; that control only works at organizational scale if there's a central registry defining which tools exist and who can call them.

Minimal scope and input validation as policy, not optional best practice

Every tool exposed via MCP should have the smallest possible scope - never full access to a system. No input coming from the agent should be trusted without sanitization, because the agent is, by definition, exposed to content it doesn't fully control (search results, external documents, another tool's response).

Logging, runtime policy, and threat modeling as a continuous cycle

GitHub recommends structured logging with correlation IDs and distributed tracing via OpenTelemetry, specifically capturing security events - authentication attempts, authorization failures, unusual patterns. That only becomes a playbook when there's a defined process for reviewing those logs, not just collecting them. Runtime policy (rate limiting, circuit breakers at the gateway) and periodic threat modeling - revisiting MCPSHIELD's list of 23 attack vectors as new tools get added - close the loop.

Human approval: where it actually needs to sit

Not every tool call needs human approval - that would make the agent useless. The playbook needs to distinguish: low-risk, read-only tools can run autonomously; tools that write, delete, or move money require a human checkpoint before executing, especially when called from automatic triggers.

The playbook's ten controls

  1. Authentication - OAuth 2.1, token validation against JWKS
  2. Authorization - scope by identity extracted from the token, not assumed
  3. Minimal scope - never full system access through one tool
  4. Input validation - never trust a parameter coming from the agent
  5. Tool registry - central inventory with owner and scope per tool
  6. Tool governance - approval process for every new tool
  7. Logging - security events captured separately from general logs
  8. Runtime policy - rate limiting and circuit breaker at the gateway
  9. Human approval - mandatory checkpoint for write/delete actions
  10. Threat modeling - periodic review against the known vector taxonomy

Sources