They often focus on whether a tool is connected and miss the more important question of which tool paths are possible. A safe read action can become unsafe when it feeds an unsafe write action. Teams should model the entire chain, because the attack surface is created by transitions as much as by individual tools.
Why Security Teams Misread MCP Risk
MCP-based integrations are often treated like ordinary app-to-app connections, but that framing misses the real exposure: the model can chain tools, re-order actions, and transform a benign lookup into a harmful write. The issue is not just whether a connector exists, but whether the agent can reach an unsafe sequence through it. Guidance from the OWASP Agentic AI Top 10 and NHIMG’s OWASP Agentic Applications Top 10 both point to the same pattern: the threat surface is created by autonomy and composition, not just by the individual tool endpoint.
Security teams also underestimate how quickly MCP turns into a secrets problem. If a tool can retrieve data, pass context, or invoke downstream actions, then the integration inherits whatever privilege the underlying secrets, tokens, and service accounts can reach. NHIMG’s State of Secrets in AppSec reports that remediation of a leaked secret averages 27 days, which is far too slow for systems that can execute multiple tool calls in seconds. In practice, many security teams discover the unsafe path only after an agent has already crossed it.
How to Assess MCP Chains Instead of Single Connectors
Effective MCP review starts with path analysis. Security teams should map each tool by what it reads, what it can write, which context it receives, and which downstream actions it can trigger. That means treating the MCP server, the model, and the connected tools as one execution chain, then evaluating the chain at runtime rather than approving tools in isolation. Current guidance suggests using policy-as-code and explicit authorization checks for each request, especially when a read action can influence a later write.
- Classify every tool by data sensitivity, side effects, and whether it can initiate another action.
- Separate read-only tools from tools with write, delete, or administrative effects.
- Require short-lived credentials and task-scoped tokens instead of standing secrets.
- Log the full chain of tool invocations so investigators can reconstruct the decision path.
- Review whether the model can be prompted, misled, or socially engineered into unsafe transitions.
That operational model is consistent with the AI Agents: The New Attack Surface report, which shows how often agents exceed intended scope, and with the OWASP Top 10 for Agentic Applications 2026, which emphasizes tool misuse and unsafe orchestration. These controls tend to break down in environments where a single MCP server multiplexes many tools behind one identity, because the team loses visibility into which specific path the agent actually took.
Where MCP Governance Usually Breaks Down
Tighter MCP governance often increases integration overhead, requiring organisations to balance developer speed against blast-radius reduction. The hardest cases are environments with broad retrieval access, shared service accounts, or tools that forward prompts and outputs without strong boundary checks. Best practice is evolving, but there is no universal standard for this yet: some teams use per-tool identities, while others enforce intent-based approval at runtime when a call would cross a trust boundary.
Edge cases also appear when teams assume a read path is harmless because it has no direct write permission. In MCP systems, a read may still expose credentials, hidden instructions, or sensitive context that enables a later escalation. That is why the question is not just “Can the tool do this?” but “Can the chain get from a harmless action to a harmful one?” NHIMG’s Analysis of Claude Code Security is useful here because it illustrates how agentic systems can appear controlled while still allowing risky transitions once tool access is composable.
In practice, MCP governance works best when security teams assume the model will eventually attempt the most permissive path available and design controls around that expectation, not around idealized usage.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | T3 | Tool chaining is the core MCP risk this control targets. |
| CSA MAESTRO | A2 | MAESTRO addresses agent orchestration and cross-tool side effects. |
| NIST AI RMF | AI RMF supports governing emergent behaviour and runtime risk in agent chains. |
Apply AI RMF to set runtime guardrails, monitoring, and escalation criteria for MCP integrations.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
