Netskope Sees Remote MCP Transactions Rise 375% as Downstream AI Data Violations More Than Double
Netskope Threat Labs’ AI Report: 2026 documents a change in enterprise AI risk direction. Organizations are still sending sensitive material into AI services, but connected systems are increasingly returning data that the requester—or another agent—was not authorized to receive.
Across the subset of Netskope customers represented in its telemetry, average downstream data-policy violations rose from 12 to 31 per organization per week over the year ending July 2026. For the top quarter of organizations, the rate increased from 72 to 206. At the same time, users of internet-hosted MCP servers increased 250% and remote MCP transactions increased 375% in just ten weeks.
Those figures do not establish that MCP caused every downstream violation. They do establish that the observable boundary is moving: enterprise AI is becoming a bidirectional application and authorization surface, not merely a prompt destination. Controls that inspect only what employees upload now miss the data and executable content flowing back.
The measured MCP growth covers remote connections only
Netskope defines the MCP measurement narrowly. It covers cases where an agent connects to an MCP server hosted on the internet, not servers running on a user’s machine or inside the organization’s network. The report identifies Claude Code and Codex among the leading clients behind those connections.
That distinction is operationally important. A secure web gateway may see a remote MCP session while remaining blind to local stdio servers, loopback HTTP, internal gateways, or tool calls executed through an IDE extension. The report’s 375% transaction growth is therefore a signal from one observable segment, not a complete count of enterprise MCP use.
The protocol’s new stateless transport model makes explicit request-level identity and authorization more important, not less. As our analysis of the MCP 2026-07-28 specification noted, removing session dependence can improve horizontal operation, but implementations still must bind each request, credential, tenant, and tool result to the correct principal.
Downstream leakage is an authorization failure at retrieval time
The report defines a downstream data-policy violation as an AI service returning information that organizational policy prohibits the user or agent from accessing. Netskope points to MCP, retrieval-augmented generation, and customized models trained on proprietary data as common settings in which the service can reach material beyond the requester’s authorization.
This is not equivalent to a user pasting a secret into a public chatbot. The sensitive object may remain inside an approved enterprise data store and still cross a boundary because retrieval, generation, or tool execution evaluates the service’s broad access rather than the caller’s narrower rights. The failure is therefore closest to broken object-level authorization or a confused deputy, with a probabilistic interface in front of it.
Defenders should also avoid treating every policy alert as confirmed exfiltration. Netskope’s category includes use-case restrictions—for example, source code returned by an application approved only for general chat—as well as access to sensitive connected data. Severity depends on the data, the requester, and whether the result left the controlled environment. The rise is a strong control signal, but incident response still requires context.
Coding agents turn downstream content into an execution path
The report found weekly use of AI code applications rising from 42% to 84% of observed organizations over the past year. Claude Code reached 75% and Codex 58%, from less than 1% each a year earlier. Netskope also measured average AI prompt volume increasing from 1,498 to 4,731 per organization per week and attributes much of that expansion to agentic use.
Higher message volume is not inherently a vulnerability. The security change is that coding agents can retrieve repository context, invoke external tools, generate commands, edit files, and execute results. A malicious response can therefore progress from “content a person might read” to “input an agent may run.” Netskope lists indirect prompt injection, trojanized AI tooling or models, vulnerable training data, emergent behavior, and hallucination as possible sources of malicious code returned by an AI service.
This compounds the supply-chain problem described in our FakeGit agent-baiting investigation: discovery and recommendation channels can steer agents toward hostile dependencies or tools, while connected assistants have the authority to fetch and execute them. Output validation must cover code, links, packages, tool metadata, and tool results—not just natural-language answers.
The dataset is useful, but it is not the whole enterprise market
Netskope says the report is based on aggregate usage data collected by the Netskope One platform for a subset of its customers from June 2025 through July 2026. It does not publish the number of organizations, their industry distribution, geography, or selection criteria on the report page.
The percentages should therefore be read as prevalence within that observed customer subset, not as a census of all organizations. Product telemetry also reflects what the platform can classify and what customer policies label as violations. It is stronger evidence of direction and control-plane load than of universal market share.
Even with those limits, the report is valuable because it separates upstream from downstream risk and ties both to actual traffic. The most actionable finding is not that one coding agent leads another. It is that organizations need to preserve user-level authorization and inspect responses at a point where agents cannot bypass the decision.
Defensive priorities
- Map every AI data path in both directions. Inventory approved and shadow AI applications, remote and internal MCP servers, local tool processes, RAG stores, model platforms, IDE agents, and CI/CD integrations. Record what telemetry exists for prompts, tool calls, results, and execution.
- Authorize at the source on every request. Do not rely on a model prompt or gateway policy to redact data after an overprivileged connector retrieves it. Propagate the caller’s identity and scope to the database, API, repository, and tool that owns the object.
- Separate service reach from user authority. If a shared agent identity must have broad access, place a policy-enforcement point between it and each data source, with tenant, purpose, object, and action checks bound to the current request.
- Inspect downstream responses before action. Apply DLP and malicious-code analysis to model output, MCP tool results, generated patches, package references, and URLs. Treat any result that can enter a shell, build, browser, or deployment pipeline as untrusted.
- Correlate identity across the full chain. Logs should connect user, agent instance, model, MCP client, server, tool, credential, retrieved object, generated artifact, approval, and resulting process or network activity.
- Constrain execution independently of content filters. Run coding agents in isolated workspaces with minimal filesystem and network access, short-lived credentials, package allowlists, protected configuration paths, and approval gates for irreversible actions.
- Measure policy quality, not only alert count. Sample alerts for false positives and missed authorization failures. Break downstream events out by sensitive-data access, prohibited use case, malicious content, and actual execution so trend lines drive the right response.
Netskope’s telemetry shows the enterprise AI boundary becoming more connected and more active at the same time. The defensive response should not be a single “AI firewall” around prompts. It should be an end-to-end authorization and execution architecture in which every retrieved object is scoped to the requester, every external result is untrusted, and every agent action is attributable and reversible.
Sources: