MCP Server Hardening & Tool Provenance

Threats mitigated

• T2 Tool Misuse

  Manipulation of tools, APIs, or environment access to perform unintended actions or access unauthorized resources, including exploitation of access to external systems.

• T12 Agent Communication Poisoning

  Injection of malicious data into inter-agent communication channels or using external systems for side channel communications and memory persistence.

• T16 Insecure Inter-Agent Protocol Abuse

  Attackers abuse the trust and control semantics of agent interoperability protocols such as MCP and A2A: manipulating server responses, injecting context, publishing misleading tool descriptions or exploiting ambiguous consent flows.

• T17 Supply Chain Compromise

  Vulnerable, malicious or outdated components enter the agent through models, libraries, tools, plugins, prompt templates, build environments or framework updates.

OWASP AISVS coverage

The AISVS 1.01 chapters and verification requirements this control helps satisfy.

C6 Supply Chain Security for Models

• C6.1.2 Level 1

  Verify that model weights, datasets, and fine-tuning adapters are downloaded only from approved sources.

• C6.1.3 Level 2

  Verify that every third-party model artifact can be integrity-verified.

C9 Orchestration & Agentic Security

• C9.3.7 Level 2

  Verify that external resources named in model output are verified against an approved allow-list or registry before the agent installs or invokes them.

• C9.5.5 Level 2

  Verify that inter-agent task delegation is restricted by an explicit authorization policy.

C10 Model Context Protocol (MCP) Security

• C10.1.1 Level 1

  Verify that MCP components are obtained only from trusted sources and cryptographically verified.

• C10.1.2 Level 2

  Verify that only allow-listed MCP servers are permitted.

• C10.1.3 Level 2

  Verify that locally launched MCP servers run in a least-privilege sandbox with restricted file system, network, and system access.

• C10.2.1 Level 1

  Verify that MCP servers validate access tokens for each request and do not rely on transport security alone.

• C10.2.4 Level 2

  Verify that MCP tools/list returns only tools permitted by the requester's authorized scopes, and that list responses vary only by authorization context, never by connection.

• C10.2.5 Level 2

  Verify that MCP servers enforce access control on every tool invocation, validating that the user's access token authorizes both the requested tool and the specific argument values supplied.

• C10.2.7 Level 1

  Verify that MCP servers only accept tokens explicitly issued for them, and do not pass tokens issued for other services through to downstream APIs.

• C10.3.1 Level 1

  Verify that authenticated, encrypted streamable HTTP is used for MCP transport for remote services.

• C10.3.3 Level 1

  Verify that MCP servers validate both the Origin header and the Host header independently on all HTTP-based transports to prevent DNS rebinding attacks.

• C10.4.1 Level 1

  Verify that MCP tools/list and tools/call responses are validated against their declared schemas before being injected into the model context.

• C10.4.2 Level 1

  Verify that MCP tools/list and tools/call responses are screened for indirect prompt injection before being injected into the model context.

• C10.4.7 Level 2

  Verify that MCP clients present users with explicit consent dialogue and cancellation options upon installation of a local MCP server.

• C10.4.8 Level 3

  Verify that MCP clients maintain a snapshot of tool definitions and that any change to a tool definition triggers re-approval before the modified tool can be invoked.

Design phase

Architecture, threat modelling and policy decisions made before code is written. 7 tasks.

Protocol Trust Model

• Inventory every MCP server, A2A peer and tool the agent can reach; classify each as local, first-party remote or third-party
• Define an allow-list of approved servers and agent cards with owner, version and permitted scopes (AISVS C10.1.2)
• Decide which actions need explicit user consent and design consent prompts that show the full action and target (AISVS C10.4.7, C10.4.20)
• Plan per-server least-privilege sandboxes for locally launched servers (AISVS C10.1.3)

Identity and Authorization Design

• Use OAuth 2.1 audience-bound tokens issued for each MCP server; never pass tokens through to downstream APIs (AISVS C10.2.2, C10.2.7)
• Bind A2A delegation to explicit, narrowly scoped tasks; authority never exceeds the delegating agent (AISVS C9.5.5, C9.5.7)
• Choose sender-constrained tokens (mTLS or DPoP) for high-risk servers (AISVS C10.3.5)

Build phase

Implementation, testing and hardening while the agent is developed. 9 tasks.

Server Admission and Integrity

• Install MCP components only from trusted sources and verify signatures or digests before launch (AISVS C10.1.1)
• Pin server and tool versions; snapshot tool definitions and block invocation after any change until re-approved (AISVS C10.4.8)
• Verify that external resources named in model output are on the approved registry before installing or invoking them (AISVS C9.3.7)

Request and Message Validation

• Validate access tokens on every request and enforce authorization per tool and per parameter (AISVS C10.2.1, C10.2.5)
• Return only the tools a caller is authorized to see from tools/list (AISVS C10.2.4)
• Validate tools/list and tools/call responses against their schemas and screen them for indirect prompt injection before adding them to the model context (AISVS C10.4.1, C10.4.2)
• Reject unknown or oversized parameters and enforce payload limits (AISVS C10.4.3, C10.4.5)

Transport

• Use authenticated, encrypted streamable HTTP for remote servers; restrict stdio to controlled local environments (AISVS C10.3.1, C10.3.2)
• Validate Origin and Host headers to stop DNS rebinding (AISVS C10.3.3) and refuse protocol downgrades (AISVS C10.3.4)

Operations phase

Monitoring, response and continuous improvement once the agent is live. 5 tasks.

Monitoring and Response

• Log every inter-agent message and tool call with server identity, tool version and authorization context
• Alert on tool-definition drift, new or unexpected servers, and recursive or looping tool calls
• Isolate an agent or server showing suspicious protocol traffic and revoke its tokens
• Re-review the server allow-list and granted scopes on a fixed schedule and after every protocol revision
• Red-team consent flows, tool descriptions and context injection paths before each release

Tools and frameworks

Protocol Security

• Specifications: Model Context Protocol authorization and security best practices, A2A protocol specification
• Gateways: MCP gateways and proxies that enforce allow-lists, token validation and response screening
• Scanning: MCP server and tool-description scanners for tool poisoning and shadowing
• Identity: OAuth 2.1 authorization servers with audience-restricted tokens, mTLS / DPoP
• Guidance: OWASP MCP Security Cheat Sheet, OWASP AISVS 1.01 chapter C10

Related controls

• M6 Comprehensive Security Monitoring & Auditing shares T2, T16, T17
• M10 Defense-in-Depth Architecture & Trust Boundaries shares T12, T2, T16
• M13 Secure Development Lifecycle Integration shares T2, T12, T17
• M2 Tool Sandboxing & Isolation shares T2, T16

References

• Model Context Protocol: Security Best Practices
• OWASP AISVS 1.01 C10: Model Context Protocol (MCP) Security
• OWASP MCP Security Cheat Sheet
• Agent2Agent (A2A) Protocol Specification
• Invariant Labs: MCP Security Notification – Tool Poisoning Attacks