Shadow AI Governance: Closing the Gap IT Never Approved

Employees do not wait for IT to approve an AI tool anymore. They connect an assistant to a shared drive, wire an agent into a support queue, or plug a coding assistant into a production repository, often without telling anyone. Security and IT teams already have a name for the unauthorized SaaS version of this problem: shadow IT. The AI version is shadow AI, and it is a harder governance problem, because these tools do not just get accessed, they act. An agent that can read a customer record, write to a pipeline, or trigger a downstream process is not a login event you can flag in an access log. It is a change to how data moves through your business, and if nobody mapped that path, nobody can govern it. For a VP of Data or a CDO, that gap tends to surface at the worst possible moment: an audit, a regulator's question, or an AI decision nobody can fully explain. Governing shadow AI starts with seeing what these tools actually touch, not just who is using them.

Shadow AI Is Shadow IT With Write Access

Shadow AI is any AI tool, model, or autonomous agent connected to company data or systems without going through IT or security's formal review and governance process. Unlike an unauthorized SaaS subscription, a shadow AI tool usually has the ability to read, transform, or act on data directly, not simply store it. That distinction is what turns it into a governance problem instead of a procurement one.

Traditional shadow IT gave security teams a discovery problem: find the unsanctioned app, understand what data it holds, decide whether to sanction or shut it down. Shadow AI adds a second layer on top of that. An AI coding assistant with repository access can change the code that defines how data is transformed. An agent wired into a CRM can write records, not just read them. Even a well-intentioned team piloting a new AI tool can quietly create a data path that finance, compliance, or the AI governance program never approved and does not know exists.

You Cannot Govern Access You Cannot See

Most governance programs still lean on identity and access tools to answer the shadow AI question, and that is where the blind spot starts. An identity tool can tell you who logged into a system and what permissions they hold. It cannot tell you what an agent actually read, what it wrote, or which downstream reports and models now depend on data that tool touched. That level of visibility is structural, not identity based. It has to come from tracing the data path itself, through the application code, pipelines, and integrations an agent actually runs on, the same ground truth that shapes how AI agents reason about data in the first place, as this look at what makes an AI agent data aware lays out.

That is a different question than "who has access," and it is the one a board or a regulator will actually ask after an incident: what did this tool touch, where did that data go, and can you prove it. Answering that requires a deterministic, code derived map of the data estate, not an inference from logs.

What the Data Shows

This is not a hypothetical risk. A survey published in September 2026 by Imprivata found that 72% of healthcare organizations already have AI tools or agents deployed without formal IT approval. A separate KLAS finding put only 4% of health systems willing to call their AI governance strategy advanced. Healthcare is the clearest example because the stakes are high and public data exists, but the same gap shows up across financial services, insurance, and any regulated industry running AI on top of established systems and application code.

What Good Looks Like

Foundational is a data and AI governance platform, and the differentiator that makes shadow AI governance possible is source code analysis. Foundational analyzes any code that touches data, not just pipelines, including application code, ORM layers, transformation scripts, notebooks, backend services, established systems, and the integrations an AI tool or agent actually runs through. That is what turns "we think this agent has access" into "here is exactly what this agent reads, writes, and depends on."

This is also where governance stops being a compliance backstop and becomes what makes AI trustworthy in the first place. A live, code derived data graph gives AI agents and models real definitions and provenance to reason from, instead of incomplete warehouse metadata, and it gives governance and compliance teams the same map to answer an auditor's question before it is asked, rather than reconstructing it after an incident. One insurance customer, Lemonade, used that complete lineage to significantly accelerate regulatory approval for AI-driven underwriting, proof that code level lineage is a practical compliance advantage, not just a security nicety.

Frequently Asked Questions

How is shadow AI different from shadow IT?
Shadow IT is an unsanctioned app someone signed up for. Shadow AI is an unsanctioned tool or agent that can read, transform, or act on your data directly. An unapproved SaaS subscription is a discovery and licensing problem. An unapproved AI agent with write access to a pipeline or a CRM is a data governance problem, because it can change what data means and where it flows, not just who can see it.

How do we find AI tools and agents that were deployed without approval?
Start with the code, not the login logs. Access and identity tools show who has permissions, not what an agent actually does with them. Tracing lineage through application code, pipelines, and integrations shows which systems an AI tool or agent is actually reading from and writing to, which is how most shadow AI gets surfaced in practice, since it rarely shows up as an obvious new application in a SaaS inventory.

Does identity and access management solve shadow AI governance?
No, and treating it as sufficient is the most common gap. Identity and access management is complementary to data governance, not a substitute for it. It tells you who can reach a system. It does not tell you what an agent read, what it wrote, or which downstream reports and models now depend on data that agent touched. Governing shadow AI requires structural, code derived visibility into the data path itself.

What does governing shadow AI actually require?
It requires seeing what every AI tool and agent in your environment actually touches, at the code level, not just which ones IT approved. Foundational analyzes source code across application layers, pipelines, and established systems to build a deterministic map of what an AI tool or agent reads, writes, and depends on, so governance and compliance teams can answer what happened, not just who had access.

Conclusion

Shadow AI is not a future risk to plan for. It is already running inside most environments today, and the tools your governance program does not know about are the ones most likely to surface during an audit or an incident. Seeing what those tools actually touch requires the same AI governance foundation as any other AI initiative: a deterministic, code derived map of the data estate. See how Foundational's AI governance and data access approach extends that visibility to every AI tool and agent in your stack, approved or not. Request a demo to see what it surfaces in your own environment.