Can I find out which AI tools are in use without asking?

Partially. Egress logs and your identity provider will show you domains and sign-ins, which tells you which services are reached and by roughly how many people. What they will not tell you is what was sent, which is the part your question is actually about. Treat that data as a population estimate, not as an inventory.

Will data loss prevention catch this?

It catches the patterns it was written for, and the highest-volume case is not one of them. Pasting a customer conversation or an internal document into a chat box produces prose, not a card number or an identifier, so it does not match. The rules that would catch it are the rules that generate enough false positives to be turned off.

Should I block the consumer AI domains?

Only with your eyes open about the trade. Blocking moves the activity to personal phones and personal accounts, where you have no telemetry at all. You convert a problem you can partially see into one you cannot see, and the behavior continues because it is useful.

What evidence will an auditor ask for?

Increasingly: which systems an assistant could reach, who could direct it, what it did, and what happens to that access when somebody leaves. If access is happening by copy and paste, none of those four have an artifact, and the honest answer is that you cannot say.

What is the fastest thing that reduces real risk?

Give the most affected team a sanctioned path to the two systems they are pasting from, with read-only access and logging. One team, two systems. It removes more volume than a policy does and it produces the evidence you are missing, which a policy never will.

Shadow AI security: what you can actually see

Shadow AI security resists the usual controls: no inventory, DLP catches the wrong half, and the ban made visibility worse. Here is what is actually knowable and what to do with it.

Nidhi KN September 18, 2026 7 min read

Your organization has a shadow AI security policy. You have probably written or reviewed it. It is a reasonable document and it is not the thing standing between you and an incident, and you know that, which is why you are reading this.

This is the version of the shadow AI problem written for the person who gets asked what happened. It is less about the phenomenon and more about which of your existing controls do and do not reach it.

Why shadow AI security controls miss

There is no inventory, because there is no procurement event. Every tool-discovery process you have assumes somebody bought something, or at minimum signed up with a company email and tripped a single sign-on record. An employee using a general assistant through an account they already had generates neither. There is nothing to discover because nothing was acquired.

Egress monitoring sees the destination, not the decision. You can see that a domain was reached and by how many people. That gives you a population estimate, which is genuinely useful. It does not tell you what was sent, and what was sent is the entire question. The gap between "sixty people use this" and "what did they put in it" is the gap your report has to close and cannot.

Data loss prevention was written for a different shape. Your rules look for structured secrets: card numbers, national identifiers, key material, documents carrying classification markers. The highest-volume case here is none of those. It is a support conversation, a chunk of a contract, a customer's history, a draft strategy document. That is prose. It matches nothing, and the rules loose enough to match it are the ones that produce enough noise to get switched off within a month.

Your ban made the telemetry worse. This is the uncomfortable one. Blocking the domains does not stop the behavior, because the behavior is useful and the alternative is a phone. What it stops is the behavior appearing in your logs. You have converted a partially visible problem into an invisible one, and the metric that improved is the one that measured your visibility.

None of that is an argument against having controls. It is an argument for knowing which questions they can answer, so you do not report an estimate as a finding.

What you can actually establish

Four things, roughly in order of confidence.

Which services are being reached, and by how many. Egress and identity provider data are reliable for this. Enough to rank, enough to size, not enough to characterize.

Which teams. Cross-referencing the above against departments is usually possible and usually the most actionable output. Shadow AI is rarely evenly distributed; it concentrates where the work is high-volume and information-heavy, which in most companies means support, sales and the part of finance that reconciles things.

What they are trying to do. This one requires asking, and it requires asking in a way that does not punish the answer. It is also the highest-value data you will get, because the systems people name are the systems that should be connected properly, ranked by demand, at no cost to you.

What has already left. You cannot establish this. Say so plainly rather than implying a number. "We cannot characterize what has been sent to unsanctioned AI services" is a finding. A confident low estimate is worse than useless, because somebody will plan around it.

The evidence question that is coming

Audit and customer security questionnaires have started asking about AI access, and the questions have a consistent shape:

Which systems can an AI assistant reach?
Who can direct it to do so?
What did it do, and when?
What happens to that access when somebody leaves?

If access is happening by copy and paste, none of these has an artifact. Not a weak artifact. None. Question three in particular has no answer at all, because pasting produces no log anywhere in your estate.

This is worth raising internally before somebody else raises it externally, because it reframes the work. The project stops being "reduce risky behavior", which competes badly for budget against risks with more dramatic failure modes, and becomes "be able to answer question three", which has a deadline attached to it as soon as one customer asks.

The intervention that works

You will not win by making the unsanctioned path harder. You win by making the sanctioned path better, and taking the logging as a by-product.

Concretely: the reason somebody pastes a customer record into an assistant is that the assistant cannot read the CRM. Connect the CRM, under conditions you set, and the paste has no reason to happen. The activity moves onto a path that logs.

Three properties make the sanctioned path defensible rather than just convenient.

Access follows the person, not the connection. If the connection decides what is reachable, then whoever set it up decided for everybody, and your support agent and your finance manager have the same reach. If each call resolves against the role of the person the assistant is acting for, one connection serves both and neither one's access is the other's.

Operations are restricted, not just systems. Reading a customer record and deleting one are different risks. A control that can only admit or deny an entire system will be set to admit, because the team needs it, and you will have gained an audit trail without gaining a boundary. Being able to block a single operation is what lets you say yes to the system.

Every call is recorded, including the refused ones. Successes tell you what happened. Refusals tell you what people are trying to do, which is your early warning that a rule is wrong or that somebody is working around it. A trail of successes only is a trail that cannot answer a security question.

What to do in the first two weeks

Size it, do not inventory it. Pull the domains from egress, map to teams, and report a ranked list with an explicit statement that content is not observable. Resist the pressure to turn it into a count of incidents.

Ask the most affected team what they are doing. Not as an investigation. The output you want is a list of systems, and people will give you one if the conversation is about tooling rather than compliance.

Sanction one path, narrowly. Pick that team and the two systems they name most. Read-only to start. The point is not coverage, it is to move the highest-volume behavior onto a path that logs, and to have something real to show when the evidence question arrives.

Write the rules before you announce it. Which roles, which systems, which operations. Doing this afterwards means narrowing from a default that people have already built habits around, which is a much worse conversation than the one you get from starting narrow.

Re-run the egress report after a month. Two outcomes, both informative. The volume for that team drops, which is the result. Or it does not, which means the sanctioned path does not cover what they actually needed, and now you know what to add.

Threats that are specific to this, not general

Two risks change shape once assistants can reach systems directly, and both are worth raising before somebody asks.

Instructions arriving inside content. When an assistant reads a support ticket, a web page or an inbound email, that content can contain text addressed to the model rather than to the reader. This is not hypothetical and it is not solved. An MCP endpoint in particular has no defense against it and cannot have one, because a server never sees the user's prompt and therefore has nothing to compare a proposed action against.

The mitigation is not detection, it is blast radius. If the assistant can only call operations that a person in that role should be able to call, the worst case of a successful injection is bounded by the same rules that bound the person. That is the argument for restricting operations rather than systems, stated in the terms your threat model uses.

Aggregation. Individually, read access to the CRM, the helpdesk and the billing system is unremarkable. Together, in a tool that can join them, they are a customer intelligence capability that no single system's access review considered. Nothing is being accessed that should not be; the combination is new.

There is no clean control for this, and claiming one would be dishonest. What helps is knowing it is true, keeping the per-call record so the combinations are visible afterwards, and being deliberate about which systems end up reachable by the same role. It is worth a paragraph in your risk register precisely because it is the risk your existing reviews are structurally unable to surface.

What to tell the board

The framing that survives contact with a budget committee is not a risk framing, because AI risk competes with risks that have more vivid failure modes.

It is this: staff have adopted a tool that makes them measurably better at their jobs, faster than any tool in recent memory, and they are using it in the only way currently available to them, which happens to be the one with no logging. The work is to give them a better way and collect the evidence on the way past.

One number carries that argument better than any risk framing. In IBM's 2025 Cost of a Data Breach report, 97% of the organizations that suffered an AI-related breach said they lacked proper AI access controls. Not that they lacked a policy, and not that staff were careless. They lacked the controls. That is a budget line rather than a behavior problem, which is the distinction that gets it funded.

That version is true, it does not require anyone to believe their colleagues are careless, and it gets funded.

The same problem as a business case, for the person who has to approve the budget, is in your staff are pasting company data into assistants. What the access rules look like once you have decided is in the mechanics of restricting an agent, and the evidence question specifically is in producing audit evidence for agent access.