Security teams are getting better at spotting which AI tools employees are using. What they often still can’t see is whether someone just asked ChatGPT to rewrite a paragraph or uploaded a spreadsheet full of customer data.
That distinction is becoming the real shadow AI problem. An inventory of unsanctioned tools can tell you where employees are experimenting, but it cannot tell you what information has already left the organization, whether that information was sensitive or whether it should have been shared in the first place.
The risk changes with the data. A developer asking Claude about a generic coding problem is very different from pasting proprietary source code into the same prompt. A salesperson summarizing public information is very different from uploading a customer list. From the perspective of traditional application discovery, those activities can look almost identical.
As companies try to get control of shadow AI, they need to look beyond which tools are being used and start paying much closer attention to what is flowing into them.
Shadow AI breaks the old shadow IT playbook
The mistake is treating shadow AI like shadow SaaS. With a traditional SaaS application, discovering the tool often tells a security team quite a bit about the risk. They can evaluate what the service does, what permissions it requests and whether employees should be using it.
With generative AI, the same application can be low risk in one interaction and a serious data exposure in the next. The difference is the information involved. A security team that only knows an employee used Claude or ChatGPT is missing the part that determines whether there is actually a problem.
AI also changes the value of excessive permissions. A stale permission used to be a latent risk that might sit untouched for years. Once an assistant can search across repositories on a user’s behalf, that same permission becomes much easier to exercise. Information that was technically accessible but difficult to find can suddenly be surfaced through a simple prompt.
That is why application visibility has to be paired with an understanding of the data behind it. Security teams need to know where sensitive information lives, how it is classified and who or what can reach it. Without knowing that, they’re left governing the AI tool while missing the exposure the tool may be creating.
Approved AI creates its own visibility problem
Unsanctioned tools are only part of the issue. Enterprise AI assistants are increasingly connected directly to internal documents, SaaS applications, cloud storage and other business systems so they can answer questions using company data.
Those connections can expose access problems that have been sitting inside organizations for years. Employees change roles while old permissions remain. Project folders stay accessible long after the work ends. Sensitive files are copied into shared locations and forgotten, and duplicate data accumulates across multiple systems.
Before AI, someone with access to thousands of files might still need to know that a particular document existed, where it was stored and what to search for. An AI assistant can make that information much easier to find by searching across repositories and pulling together relevant material in response to a simple request.
The underlying permission problem may be old, but AI makes that access much easier to use. Approving an AI application doesn’t mean everything behind that application is appropriately exposed. Companies still need to understand what information the tool can reach and whether the users or agents interacting with it should have that access.
Controls need to follow the data
Once security teams understand the data involved, they can be more precise about how AI use is handled. If an employee attempts to send regulated customer information to an unapproved AI service, that should be treated differently from someone using the same service to work with public information. The application may be identical, but the exposure is not.
That gives companies more options than simply allowing or blocking an AI tool for everyone. Security teams can put stronger controls around sensitive information while allowing lower-risk uses to continue. They can also identify when sensitive data is being pasted, uploaded or otherwise sent somewhere it should not go.
The same thinking applies to sanctioned AI. If an approved assistant can surface a confidential file because of an old permission, security teams need visibility into that exposure. Approval of the tool cannot substitute for understanding the data and access behind it.
Agents make broad access harder to ignore
This gets more important as companies move beyond assistants that answer questions and toward agents that can take actions across business systems. An agent may be able to retrieve information, update records, move files, send messages or interact with other applications. If its access is broader than it needs to be, that gives the agent more data and more places to act than its job requires.
Companies should know what sensitive information an agent can reach before giving it that level of autonomy. They also need to revisit those permissions as the agent’s role changes, new systems are connected or the underlying data changes.
Data visibility and access governance become closely linked at that point. Security teams need to understand both what the agent can do and what information sits within reach when it does it.
The tool list will keep changing
New models, assistants and agents will keep appearing, and employees will keep finding ways to use them. Security teams should absolutely know which tools are entering the business, but an application inventory cannot tell them whether sensitive information has actually been exposed.
A customer record uploaded to ChatGPT, source code pasted into Claude or a confidential file surfaced by an approved assistant are very different events from simply detecting that those applications are in use. That is the level of visibility organizations need as AI becomes more deeply embedded in everyday work.
The question security teams ultimately need to answer is not only which AI tools people are using. They need to know what company data those tools are touching, who or what can reach it and when that information is going somewhere it should not.
