How to Track Data Moving Between Employees and AI Systems and Identify What Remains Invisible
Published
Question: Netskope’s 2026 AI Report says MCP connections and autonomous agents allow data, instructions, and code to move from employees to AI services and back into the organization. How can organizations monitor information exchanged across models, agents, tools, data stores, MCP servers, and third parties? Which interactions can currently be monitored? Which remain unmonitored? And why?
Ray Canzanese, Director of Netskope Threat Labs
In recent years, AI security has largely focused on preventing sensitive data from being uploaded into AI prompts. Today, with AI agents fetching information directly from company databases, securing downstream traffic (the information AI models and agents are allowed to return to users) is necessary.
Our report shows that sensitive data appearing in models and agents’ output is now the second and fastest-growing vector of data policy violations, with an average of 31 alerts per week per organisation, up from 12 a year ago.
Connections to third-party MCP servers and repositories are also increasing, and their security needs to be evaluated before they are established. Managing this process manually is not sustainable.
Tools that can automate dynamic risk scoring of AI apps and third-party MCP servers based on their authentication standards, protocol versions, and vendor trust scores are necessary to adjust data protection policies in real time automatically. Such tools can also determine which data is allowed to flow to these locations.
These examples illustrate the variety of challenges that AI adoption presents to security teams and the need for bespoke monitoring and governance capabilities. The core foundation typically consists of an AI gateway that serves as a mandatory checkpoint for all AI traffic, where AI-specific security and data protection policies are applied.
Those checks should at least include:
- zero trust identity and contextual policies (who / what is making the request and are they authorised to?)
- real-time upstream and downstream data loss prevention (DLP) policies, including for MCP payloads (is this data allowed to go to this MCP server, AI app or user?)
- behavioral analytics (is this agent or human behaving abnormally? Are there signs of AI compromise?), and
- threat protection (is a compromised AI model delivering users malicious content?).
For these policies to be effective, security teams need to identify all active agents, MCP servers and AI tools (coding assistants, etc.) operating within their network, because as long as shadow AI exists, some AI traffic and data movements will remain invisible.
Data lineage can help here. It enables organisations to track and document how data is created, who interacts with it, the transformations it undergoes, and its successive movements across systems.
This is an additional level of visibility that can help discover hidden AI usage through data’s journeys, and more effectively apply AI security policies.
Technically, most AI workflows, including MCP traffic or AI API calls, can be monitored. But even with sophisticated AI security capabilities, a couple of scenarios will still present a challenge:
- Employees using and sharing work-related information to personal AI accounts or devices. With DLP policies in place, employees shouldn’t be able to extract sensitive corporate information from the organisation’s network, but bypassing them is not impossible.
- Once the data is on a personal account or device, security has no visibility or control over its movements.
- Local AI models running on a user’s laptop or computer without internet access, making them invisible to network security tools.
- Background cloud-to-cloud connections where one SaaS/cloud service calls a third-party AI provider directly, for example, a CRM tool summarising records via an external LLM API.
- In such instances, traffic bypasses the corporate network entirely. However, organisations with API-based CASBs or direct visibility into a SaaS platform’s logs may still catch these calls after the fact.
Related
