Why do companies have no visibility into what staff share with AI tools?

Because the content travels inside encrypted connections to services the company does not control. When someone pastes text into a chatbot in a browser, the firewall sees an HTTPS connection to the provider, and at most the name of the service; the prompt itself is encrypted end to end between the browser and the provider. Personal accounts keep the history on the provider's side, out of the company's reach. AI features inside approved apps look like ordinary traffic to those apps, and phones on mobile data never touch the company network at all. Getting content-level visibility needs control at one of the ends: a business account whose admin console and audit logs show usage, data-loss prevention in the browser or on the endpoint, or an interception proxy, each with its own privacy questions. What the network can give you is the next best thing: which hosts use which AI services, when and how much. NetSenX shows exactly that from the Pro plan.

Shadow AI: what it is and how to find it

Shadow AI is the use of AI tools at work that the people responsible for IT, security and data protection have not approved and usually do not know about: a chatbot used with a personal account, an AI feature switched on inside software the company already pays for, a browser extension, a coding assistant, a language model running on a laptop, or an AI agent connected to company systems. It is rarely malicious. People want to work faster, and the tools are a browser tab away. The problem is that nobody can answer three questions an auditor, a customer or a regulator will ask: which AI services touch our data, what goes to them, and under which terms.

This guide covers why that matters, how to find shadow AI from the network without installing an agent on every device, what the network cannot tell you, and a policy checklist you can adopt this quarter.

Why shadow AI matters

Data leaves without a contract. Text pasted into an AI service is processed by that provider. With a business account and a data-processing agreement, that can be lawful and controlled. With a personal account on consumer terms, the company has no agreement, no say over retention and often no way to find out what was sent. Under the GDPR, sending personal data to such a provider needs a legal basis, transparency towards the people concerned and, where the provider acts on your behalf, an agreement under Article 28. An unauthorised disclosure can be a personal data breach, with the 72-hour notification duty of Article 33 where it is likely to result in a risk to people.

The AI Act asks you to know your tools. Article 4 of the AI Act, Regulation (EU) 2024/1689, has applied since 2 February 2025 to providers and deployers alike, which includes ordinary companies that use AI tools. It asks for measures that support the AI literacy of the staff who deal with AI systems. You cannot plan literacy measures for tools you do not know are in use.

NIS2 treats AI services as suppliers. For organisations in scope of NIS2, Directive (EU) 2022/2555, Article 21 lists supply-chain security among the risk-management measures. An AI service that receives company data is a service provider in that sense, whether procurement signed for it or not.

Customers ask. Security questionnaires and tenders increasingly ask whether customer data is entered into AI tools, and which ones. "We do not know" is the answer that costs deals.

How to find shadow AI from the network

A network sensor sees every device on the segments it watches, including the ones that cannot run an agent and the laptops nobody enrolled. It does not decrypt anything. What it sees is enough to answer "what is in use":

The service. Before encryption starts, a TLS connection names the server it wants in the handshake (the server name, SNI), and the device has usually asked DNS for the same name a moment earlier. Together with the destination address, that identifies the AI service.
The device. Each connection belongs to a host, so you can tell which machines or network segments use which services, and when.
The volume. Bytes sent separate a quick question from a large upload. A workstation that sends hundreds of megabytes to an AI service in an afternoon is worth a conversation; a few kilobytes are not.
Local models. A language model served on a laptop or a GPU workstation answers on the local network. Its runtime traffic is visible, and so is a model server that other machines start to call.
Agents and remote connectors. An AI agent that runs on a server calls model APIs on a schedule or in bursts, often at night, and may also reach internal systems. Remote MCP connectors appear as connections from the machine running the assistant to the connector's host.

What the network cannot see matters as much:

Content. Prompts, pasted documents and answers travel inside encrypted sessions. Judging what was shared needs the AI service's own admin logs or a data-loss-prevention tool.
What happens on the device. A local MCP server that talks to the assistant on the same machine never touches the network, and neither does an AI feature that runs entirely on the laptop.
Traffic outside your networks. A phone on mobile data or a laptop on home Wi-Fi is out of view, unless that traffic comes back through a company VPN.
Hidden server names. Where Encrypted Client Hello is in use, the server name is no longer readable in the handshake, and DNS and the destination address carry the identification instead.

A practical policy checklist

Inventory first. List the AI services you pay for, the AI features switched on in software you already use, and what the network shows on top. Give each service a status: approved, tolerated for non-sensitive data, or to be replaced.
Offer an approved tool. A business account with a data-processing agreement and training on your data switched off removes most of the reason people use personal accounts.
Classify the data. State which data may never go to an external AI service (customer personal data, credentials, source code under contract, unreleased financials) and which may.
Cover connectors and agents. Publish an approved list of MCP servers and agent integrations, scope their tokens narrowly, rotate them and include them in offboarding.
Check the identity provider. New OAuth grants to AI applications with broad scopes are the fastest-growing access path nobody reviews.
Train, and keep a record. Article 4 does not prescribe a certificate or a number of hours; it asks for measures fitted to people's role and the tools they use. Keep a simple record of who learned what and when.
Measure again. Repeat the inventory every quarter. New AI features arrive with ordinary software updates.
Answer customers from evidence. Keep a short, true statement of which AI services are approved and how use is checked, and update it when the inventory changes.

How NetSenX shows it

From the Pro plan, NetSenX flags traffic to external AI services and to locally run language-model runtimes, and shows which host reached which service, when and how much data moved. It works from traffic metadata and never decrypts anything, so no prompt content reaches NetSenX, and customer data stays in the EU. It does not read prompts, does not block AI services and does not decide which ones are allowed: those decisions belong in your AI policy, and enforcement belongs in your proxy, your firewall or the service's admin settings. The details are on the shadow AI detection page, and the step-by-step version of the inventory is in how to find shadow AI in your company.

Sources

Written by the NetSenX Team at TriStiX S.L. Questions: info@netsenx.com.

Questions this guide answers

What is shadow AI?

Shadow AI is the use of AI tools at work without the knowledge or approval of the people responsible for IT, security or data protection. It covers employees using personal chatbot accounts for work tasks, browser extensions with built-in AI, AI features switched on inside existing software, developers running local models or coding assistants, and AI agents connected to company systems. It is usually well-meant: people want to work faster. The risks are concrete. Company or customer data goes to providers you have no contract with, under terms that may allow them to keep or train on it. Personal data may be processed without a legal basis. Outputs enter documents and code without review. And nobody can answer a client or an auditor who asks which AI services touched their data. The answer is not a ban but visibility, an approved alternative and a clear policy. From the Pro plan, NetSenX shows which hosts connect to which AI services and how much data goes there, not what was typed.

Which AI services does our company actually use?

Usually more than anyone has listed, and the gap is the point of finding out. A realistic list has four layers: the services you pay for on company accounts; AI features switched on inside software you already use, such as office suites, CRM, helpdesk and design tools; services staff reach with personal accounts in the browser or on desktop apps; and models running locally on laptops, build servers or GPU workstations. Start with what you know, from contracts, card statements and admin consoles, then add what the network shows. Group the results by business function, because finance, sales and development tend to use different tools for different data, and give each service a status: approved, tolerated for non-sensitive data, or to be replaced. The list is the basis for your AI policy, your AI Act literacy training and answers to customers. From the Pro plan, NetSenX shows which hosts reach which external AI services and local model runtimes, when, and how much data goes to each; it does not show what was typed.

Can DNS logs show shadow AI use?

Partly. DNS logs show which hosts look up the domains of known AI services, which is a good start and costs nothing if your resolver already logs queries: export a week of lookups and match them against a list of AI service domains. They miss encrypted DNS that bypasses your resolver, services reached through other domains or content-delivery networks, AI features built into tools you already use, and how much data actually moved. They also show the host, not the person, and a single lookup may come from a browser preloading a page. Treat DNS as the cheap first view and confirm with connection data before you act. NetSenX combines destinations with connection volume and timing, from the Pro plan, so you see which hosts use which AI services, including local model runtimes, and how heavily; it does not see the content of prompts. Pair it with your AI provider's admin logs for the content side.

Employees bring their own AI tools to work. What is the risk?

Mainly that company data leaves under terms nobody agreed to, and that nobody can account for it later. Bring-your-own AI covers personal chatbot subscriptions, AI apps on private phones, browser extensions, AI meeting recorders and models run on personal hardware. The data risk: documents, customer details or recordings go to providers with consumer terms, possibly outside the EU, without a data-processing agreement, and stay in personal accounts after the employee leaves. The quality risk: work products built on outputs nobody checked. The compliance risk: you cannot answer a client, an auditor or a data subject who asks where their data went. AI meeting recorders deserve special attention, because they capture other people's voices and words, often without everyone's consent. The practical answer is to offer a good approved tool, say clearly which personal tools may be used for what, and require that meeting recording is announced. From the Pro plan, NetSenX shows which AI services company devices reach; personal phones on mobile data stay outside any network view.

What is a shadow MCP server and why is it a risk?

A shadow MCP server is a Model Context Protocol server that someone connected to an AI assistant without IT knowing, usually to save time: a connector to the company mailbox, a file share, a code repository, a database or a ticketing tool, installed from a public listing or written in an afternoon. The risk is that it quietly creates a new access path. It often holds a personal access token or API key with broad rights, stored in a configuration file on a laptop; it may come from an unknown author and update itself; it lets the AI act on company systems with that person's permissions; and anything the AI reads, including a malicious instruction hidden in a document or web page, can steer what it does through that connector. Nobody reviews or logs it, and it survives the employee's departure if the token is not revoked. Practical steps: publish an approved list of MCP servers, scope tokens narrowly and rotate them, check identity-provider logs for new OAuth grants to AI clients, and include connectors in offboarding. A network sensor sees connections from a laptop to remote services, not the MCP configuration on it.

How do I discover AI agents running in our company?

Look where agents get their power: identities, connectors and automation platforms, then confirm with network traffic. An AI agent is software that uses a language model to decide on and carry out steps, such as reading tickets, querying systems, writing code or sending e-mails, usually through API keys, service accounts or OAuth grants. So the best first sources are your identity provider and SaaS admin consoles: new OAuth applications with broad scopes, service accounts or personal tokens created recently, and AI features with connectors switched on. Then check automation and low-code platforms, CI pipelines and developer machines for agent frameworks and MCP servers, and ask teams directly, because many agents are pilots nobody has registered. The network adds the behavioural view: which servers or workstations call AI APIs regularly, at night or in bursts, and which also reach internal systems. From the Pro plan, NetSenX shows which hosts talk to which external AI services and local model runtimes and how much data moves. It does not identify an agent by name, and the agent-specific behaviour signals described elsewhere are not yet alerts.

How do we check whether staff follow our AI policy?

Compare what the policy allows with what the company actually uses, from three sources. First, the admin consoles of the approved AI services: who has an account, how active it is, which features and connectors are switched on. Second, identity and expense data: sign-ins with company e-mail addresses to services nobody approved, and AI subscriptions on company cards. Third, the network: which devices connect to which AI services, including local model runtimes, and how much data goes to each. A good monthly report shows the approved services and their use, the unapproved ones still in use, and any unusually large transfers, so that the conversation is about facts, not rumours. Keep it about tools and devices rather than individuals unless there is a specific concern, and involve HR or the works council where your country requires it. From the Pro plan, NetSenX gives the network view: hosts, AI services and volumes over time. It does not read what was typed and does not block anything.