Static scanning misses the behaviours that matter most, including runtime tool misuse, prompt manipulation, and covert forwarding through seemingly normal responses. A server can look harmless in a file scan but become dangerous once the model starts using it. Effective governance needs behavioural monitoring, not just configuration review.
Why This Matters for Security Teams
Static scanning answers a narrow question: what is present in the mcp server configuration, code, or package manifest at rest. That misses the security properties that matter once a model starts invoking tools, chaining requests, and forwarding data through ordinary-looking responses. The difference is not theoretical. In the State of MCP Server Security 2025, Astrix Security reported that only 18% of MCP deployments implement access scoping for tool permissions, which means most environments still rely on trust in the server itself rather than control over runtime behaviour.
For MCP, the real risk is behavioural. A server can pass a static review and still become dangerous when a model uses a tool in an unexpected sequence, requests broader context than intended, or relays sensitive material through a response that looks benign to a scanner. That is why current guidance increasingly treats MCP governance as an execution-time problem, not a file-review problem, and why the OWASP Agentic AI Top 10 is relevant even when the immediate concern is “just” a protocol server. In practice, many security teams discover dangerous tool behaviour only after an agent has already used the server in production, rather than through intentional pre-deployment review.
How It Works in Practice
Static tools are still useful for finding obvious issues such as hard-coded secrets, unsafe defaults, or exposed endpoints, but they do not validate how an MCP server behaves under model-driven use. The missing layer is runtime governance: inspect each request, understand the tool being called, evaluate the context, and decide whether the action is consistent with policy. That is closer to policy-as-code than to traditional vulnerability management.
Practitioners usually need three controls together. First, scope tool permissions so the server only exposes what the agent actually needs. Second, place runtime monitoring around tool invocation, because a “safe” tool can still be abused through prompt manipulation or excessive chaining. Third, reduce the blast radius of any credentials the server can reach, especially when the server can forward data or request downstream access on behalf of the model.
- Use behavioural logging for tool calls, arguments, and response patterns, not only configuration scans.
- Apply least privilege at the tool and resource level, not just at the server process level.
- Review whether secret material can be retrieved or relayed during ordinary model interactions.
- Treat abnormal tool sequences as policy events, not just observability noise.
This is consistent with the emerging direction in OWASP Agentic Applications Top 10 and the protocol-focused guidance in the OWASP Top 10 for Agentic Applications 2026. These controls tend to break down in environments where MCP servers are treated as trusted internal utilities and granted broad network reach, because scanners cannot see the model’s live decisions or downstream tool chaining.
Common Variations and Edge Cases
Tighter runtime control often increases operational overhead, requiring organisations to balance visibility and containment against latency, developer friction, and false positives. That tradeoff matters because not every MCP deployment has the same exposure profile. A read-only knowledge server is not the same as a server that can query internal systems, mutate records, or forward secrets to other tools.
Current guidance suggests using different assurance levels based on blast radius. Static scanning may be adequate for low-risk, low-privilege servers, but it is not sufficient for servers that can access credentials, call external APIs, or mediate actions that affect production systems. Where the server is embedded in an agentic workflow, behavioural controls become more important than package hygiene.
Edge cases also matter. A server can appear harmless if its configuration is clean, yet still be vulnerable if the model can coerce it into returning hidden context, overbroad search results, or data that later gets forwarded outside the intended boundary. For that reason, the best practice is evolving toward continuous monitoring, scoped permissions, and explicit runtime policy enforcement rather than one-time static review alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Addresses prompt manipulation and unsafe tool use in agentic workflows. |
| CSA MAESTRO | M1 | Focuses on runtime trust and orchestration risks in agentic systems. |
| NIST AI RMF | GOVERN | Requires governance for AI system behavior, not only static configuration. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Credential exposure in MCP configs makes secret handling a direct NHI risk. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control is central when MCP tools can trigger actions. |
Limit tool permissions to the minimum required and review them as part of access governance.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
