Put them in the hands of an AI agent operating through MCP, and you get a lateral movement path that bypasses every perimeter control your SOC has ever built.
This is the toxic tool chain problem. Not a vulnerability in any individual tool. Not a misconfiguration. It is what happens when an AI agent chains safe tools together into sequences no human would ever authorize, and no traditional detection rule would ever catch.
Why Individual Tool Safety Is Not Enough
The standard enterprise security model assesses tools in isolation. Review data access, approve or deny, and move on. That model was built for humans operating one tool at a time.
AI agents do not work that way.
An MCP-connected agent can access every permitted tool simultaneously, sequentially, and autonomously, without a human authorizing each step. GitHub has read access to your code. Slack has access to your internal channels. Your CI/CD pipeline has write access to production. Evaluated individually, those permissions look fine. An agent that reads from GitHub, posts findings to Slack, then pushes a modified deployment through CI/CD has just moved from code reconnaissance to production compromise, in a single automated session, with zero human login events.
That is a toxic tool chain.
Three High-Severity Chain Scenarios
Scenario One: GitHub Plus CI/CD, Reconnaissance to Production
An agent with code review access reads a repository, modifies a file to include a backdoor, then triggers a CI/CD build. Three individually routine events. Together, they form one complete kill chain.
Your SOC sees: a service account reading GitHub (normal), a file commit (normal), a pipeline trigger (normal). No anomaly fires. No human credentials were stolen. The production environment is compromised through a legitimate build from a legitimate-looking commit.
Risk score: 10/10. Do not deploy without runtime controls.
Scenario Two: Slack Plus Google Drive, Summary to Exfiltration
An AI assistant agent has access to Slack and Google Drive. Its Google Drive tool description has been poisoned; a hidden instruction tells it to retrieve files matching specific patterns and attach them to an outbound Slack message to an external Slack Connect workspace.
The agent follows the instructions. Google Drive retrieves the documents. Slack delivers them externally. Your data left the organization via two sanctioned productivity tools during two routine API calls, with zero DLP alerts.
Risk score: 8/10. Runtime monitoring is required before deployment.
Scenario Three: Jira Plus Cloud Infrastructure; Ticket to Persistence
An agent with Jira access and cloud provisioning permissions reads a ticket; engineers commonly paste environment variables and API keys into Jira comments. It extracts the credentials. It uses the cloud API to spin up a new compute instance.
The attacker now has a persistent foothold in your cloud environment, provisioned through a legitimate agent using credentials retrieved from a project management tool. Jira is not in your threat model. It should be.
Risk score: 10/10. Do not deploy without controls.
The Tool Risk Scoring Matrix
Score every MCP tool combination across four dimensions before any agent deployment. A total of 7 or above requires runtime monitoring. A total of 10 or above requires an explicit security review before go-live.
Data Sensitivity Access (0–3)
0 = No sensitive data / 1 = Internal communications / 2 = Code or business documents / 3 = Credentials or secrets
Execution Capability (0–3)
0 = Read-only / 1 = Write within contained environment / 2 = Deployment or automation / 3 = Production or infrastructure access
External Egress Potential (0–2)
0 = Fully internal / 1 = Monitored external connections / 2 = Low-visibility external channels (Slack Connect, webhooks)
Correlation Visibility in SOC (0–2)
0 = Both tools correlated in SIEM / 1 = One tool monitored / 2 = Neither tool generates correlated alerts
Total your score. Below 7: standard monitoring is sufficient. 7–9: high-severity, enforce least privilege, and add session logging. 10 and above: Do not deploy until a security review approves the permission set.
What Detection Actually Requires
Your current SIEM cannot catch this. It aggregates logs from individual systems but is not designed to correlate events across multiple SaaS APIs under a non-human identity in real time within a single agent session.
Three capabilities your stack needs that it almost certainly lacks today.
Session-Level NHI Correlation.
Every action an agent takes must be tagged to its session and correlated across tool calls. The session is the unit of analysis, not the individual API call. GitHub read, file commit, and CI/CD trigger events that occur within 60 seconds under the same NHI session ID should fire a single correlated alert, not three separate low-priority log entries.
Tool Call Parameter Logging.
Knowing an agent called the Slack API is not enough. Your detection requires the following parameters: channel, internal or external destination, and content type. Without parameter-level MCP logging, the exfiltration signal in the Slack and Google Drive scenario is invisible.
Per-Agent Behavioral Baselines.
An agent who normally reads GitHub and posts to a single internal Slack channel has an established baseline. When it first accesses Google Drive or messages an external Slack Connect workspace, that deviation is your detection signal. No baseline, no deviation, no alert.
Unosecur's MCP Gateway provides all three at the protocol layer. Every tool call passes through the gateway, is authenticated, authorized against a defined policy, and logged with full session context. When a sequence matches a toxic chain pattern or deviates from baseline, the gateway flags it in-session, before the chain completes.
Three Actions for SOC Teams Today
Map every tool combination your agents can access.
List all MCP tool pairs across current deployments. Apply the scoring matrix. Any combination of 7 or more requires immediate attention, reduced permission, enhanced monitoring, or both.
Audit Agent Permissions Against Actual Task Scope.
An agent that summarises meeting notes does not need GitHub write access. An agent doing code review does not need access to Slack Connect external workspaces. Over-provisioning at deployment is the root cause. Enforce least privilege before production, then re-check permissions after the first incident.
Get MCP Tool Call Logs into Your SIEM Now.
If agents are already deployed and cannot be immediately re-scoped, the minimum viable step is ingesting MCP tool call logs into your SIEM with NHI session tagging. It does not provide full session correlation out of the box, but it provides the raw data to start building detection rules for your highest-risk combinations.
The tools are not the problem. The chains are. The chains remain invisible until someone specifically looks for them.





%201.png)


