Notifications
Clear all
Topic starter
18/08/2026 2:42 pm
TL;DR: MCP risk is continuous, not a one-time approval problem, and Equixly maps the NSA’s MCP guidance to the OWASP MCP Top 10 by showing how tool poisoning, scope creep, secret exposure, command injection, and shadow servers can be tested before they cause damage. The practical shift is to treat MCP servers as mutable, inspectable attack surfaces that need repeated validation, not trust by default.
NHIMG editorial — based on content published by Equixly: Mapping NSA’s MCP guidance to the OWASP MCP Top 10
By the numbers:
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: What do security teams need to verify before exposing an MCP server to users?
A: Teams need to verify who can register as a client, what scopes they can request, how tokens are validated, and how consent maps to real tool permissions.
Q: Why do MCP servers create new identity risk for AI-native development?
A: MCP servers create risk because they extend delegated access from the model into repositories, data, and workflow tools.
Q: What breaks when tool descriptions can change after approval?
A: The original consent no longer matches the actual behaviour the model sees.
Practitioner guidance
- Hash and revalidate tool metadata Record the exact tool description, permissions, and version at approval time, then compare them on every reconnect or configuration refresh.
- Test declared scope against actual runtime permission Build negative tests that call each MCP tool with parameters or actions outside its declared scope.
- Shorten token lifetime and verify expiry rejection Use narrow token scope, short expiry, and replay protection for every MCP interaction.
What's in the full article
Equixly's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step MCP test cases for token exposure, scope creep, and tool poisoning that can be reused in a security validation pipeline.
- The exact mapping table between NSA guidance and OWASP MCP Top 10 failure modes for teams formalising controls.
- Practical checks for shadow MCP servers, including network discovery and inventory comparison methods.
- Runtime examples showing how malicious tool description changes can be detected before an agent acts on them.
👉 Read Equixly's mapping of NSA MCP guidance to OWASP MCP risks →
MCP security risks mapped to NSA guidance: how should teams test?
Explore further
18/08/2026 3:26 pm
Approval-based trust is the wrong control model for MCP. MCP changes after approval can invalidate the original security decision, so a one-time allowlist is not a governance control. The real issue is mutable intent inside tool metadata and runtime behaviour. Security teams should treat tool approval as the start of continuous verification, not the end of risk review.
A question worth separating out:
Q: Who is accountable when an MCP connector exposes sensitive data or actions?
A: Accountability should sit with the team that owns the server, connector, and downstream access policy, not with the protocol itself. Organisations need clear ownership for approval, monitoring, incident response, and revocation. Without that assignment, agentic access grows faster than governance can follow it.
👉 Read our full editorial: Mapping NSA MCP guidance to OWASP risks for secure testing
