Notifications
Clear all
Topic starter
15/08/2026 6:07 pm
TL;DR: MCP-connected AI agents can chain individually safe tools into lateral movement paths that bypass perimeter controls, according to Unosecur, with scenarios spanning GitHub to CI/CD, Slack to Google Drive, and Jira to cloud provisioning. The real issue is session-level correlation and permission scoping, because tool safety alone does not stop autonomous sequence abuse.
NHIMG editorial — based on content published by Unosecur: Toxic Tool Chains: How Safe MCP Tools Become Lateral Movement Vectors
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: What breaks when AI agents can chain tools through MCP without tight policy controls?
A: What breaks is the separation between request, authorisation, and execution.
Q: Why do MCP tool chains increase lateral movement risk?
A: Because MCP gives an agent programmatic access across multiple enterprise tools, so access approved in isolation becomes a cross-system path at runtime.
Q: How should teams decide whether MCP access is safe enough to allow?
A: Teams should allow MCP access only when the agent or server can be bounded with explicit scopes, revocable credentials, and traceable client registration.
Practitioner guidance
- Map tool combinations before deployment List every MCP tool pair and multi-step chain an agent can access, then score each combination for sensitivity, execution power, egress, and SOC visibility.
- Scope access to the actual task Remove write access, external workspace access, and cloud provisioning rights from agents that only need read-only summarisation or narrow support tasks.
- Tag and correlate every agent session Ensure tool call logs include a stable NHI session ID so GitHub reads, Slack posts, Jira actions, and CI/CD triggers can be reconstructed as one sequence.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- The full scoring matrix with the exact thresholds used to separate standard, high, and do-not-deploy chains.
- Protocol-layer logging and session tagging examples for MCP tool calls across GitHub, Slack, Jira, and CI/CD.
- Detection logic ideas for correlated NHI session behaviour that fit into an existing SIEM workflow.
- Practical deployment guardrails for reducing agent permissions before production use.
👉 Read Unosecur's analysis of toxic MCP tool chains and lateral movement risk →
MCP toxic tool chains: are your controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
15/08/2026 6:15 pm
Toxic tool chains are the right name for the MCP problem because the danger is in composition, not capability. Individual tools can pass review and still create an unsafe runtime path when an agent combines them in sequence. That breaks the old governance assumption that safe components remain safe when linked by a non-human identity. Practitioners should evaluate the chain as the security object, not the tool list.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
- Only 52% of companies can track and audit the data their AI agents access, which leaves 48% operating with a compliance and investigation blind spot.
A question worth separating out:
Q: Should organisations block all MCP-connected agents until controls improve?
A: Not necessarily, but they should block high-risk combinations until they can prove session-level correlation, least privilege, and parameter logging. Agents with production write access, external egress, or credential-bearing data access deserve the strictest review first.
👉 Read our full editorial: Toxic tool chains in MCP turn safe tools into lateral movement
