Shadow AI: When Approved Experiments Create New Shadows

An AI innovation team is asked to build a customer support assistant in two weeks. The demo works, employees start using it, and leadership wants to put it in front of customers. Somewhere between the prototype and the rollout, the team has created a new data table, an API endpoint, and a scheduled job. The project has a sponsor. Does every piece across the customer support assistant have an owner?

This is a hypothetical scenario, but it captures a risk that is easy to miss: an approved AI initiative can produce agents and infrastructure that were never individually reviewed. To understand the resulting shadow AI risk, security teams need to follow what a project creates and changes, not only the AI tool that started it.

The Innovation Mandate Creates a Visibility Gap

In Microsoft's 2025 Work Trend Index, 78% of leaders surveyed said they were considering hiring for new AI roles. An AI engineer or innovation team may be given a simple mandate: turn ideas into working internal tools quickly, show value, and bring successful projects to wider or customer-facing use. Speed is part of the job, and a useful pilot can become a business dependency before the team has mapped everything built to support it.

These teams may have an approved budget, an approved AI platform, and access to development environments. That approval does not register every agent they build or review every service they deploy. An approved platform can still contain agents, tools, and connections that nobody registered or reviewed.

The distinction matters. An approved pilot agent is not automatically shadow AI. A specific agent becomes shadow AI when it runs outside the organization's review, inventory, or oversight. A database table or API created along the way is a separate unreviewed asset. The project can be visible while parts of its operating footprint are not.

Follow the Quick Win Beyond the Demo

Return to the hypothetical support assistant mentioned above. The team asks a coding agent to make the support assistant answer questions about current customer tickets. But, the coding agent has not been included in the organization's AI inventory or permission review. In this example, it has tools with repository, database, and deployment permissions. It creates a table of ticket excerpts, adds an internal API that reads the table, and deploys a scheduled container job to refresh it. The job uses a service identity to read the ticket system and write to the table.

Each step has a plausible purpose. Together, they form a new chain of access and data movement: Ticket system → scheduled job → copied table → API → support assistant → users

The coding agent can make these changes because the team has given it suitable tools and credentials. In this scenario, it uses the permissions it already has to create several connected resources in one workflow. Human engineers could also build these components with AI-generated code. Either way, the project has created more than an assistant: it has created a new data flow and supporting infrastructure that needs to be accounted for.

Now the internal support assistant proves useful and becomes customer-facing. The audience, consequences of an error, and need for operational support have changed. Yet the original pilot approval may say little about the copied ticket data, the endpoint's authentication, the container's credentials, or who will maintain them. A routine application inventory might find some of these resources while missing their connection to the assistant and its business purpose.

The Shadow Can Outlive the Agent

An API inventory can tell security which endpoints exist. It may not show which unreviewed coding agent created one, what else that agent created, or what remains after the pilot. The agent is an actor in the asset story as well as an asset to review.

Disabling the coding agent stops its future work. It does not necessarily delete the copied table, retire the API, or stop the scheduled job it deployed. The support assistant may still use those resources. Even if the assistant is later retired, each dependency must be reviewed and removed or given a continuing owner.

This creates three practical questions for the organization:

• Where did the data go? A copied table may contain customer information long after the original use case changes or ends.
• What is still reachable? The API may remain accessible, the container job may keep running, and the service identity may retain access after the assistant stops.
• Who is accountable? The innovation team may hand the pilot to another group or move to its next project. Without a named owner for each dependency, maintenance and retirement become guesswork.

Finding the coding agent therefore leaves a second question: what else did the project create, and which of those resources are still active?

Discover the AI Ecosystem, Not Just the App

Assume the support assistant is already in use. Security may know which AI services employees access, yet still have no record of the coding agent that built it, the tools attached to that agent, or the data and infrastructure connected to the finished assistant. An employee usage report answers which services people use. An agent inventory must go deeper, showing what was built inside those services and what it can reach. For example, AI application discovery identifies services employees access, while an agent inventory can capture agents, tools, knowledge sources, connections, authentication context, and triggers.

To recognize the risk in our example, security needs a connected view of:

• Where AI runs: AI services, features inside approved platforms, cloud projects, and coding agents on employee devices.
• What people build there: custom GPTs, assistants, agents, and automated workflows, including who created them and who owns them now.
• What each one can reach: connected tools, APIs, MCP servers, database connections, service identities, and the permissions behind them.
• What data and assets are involved: uploaded knowledge files, live data sources, copied tables, tool activity, and the APIs or jobs an agent created or changed.

The relationships between these layers reveal the risk. A list of AI services cannot tell you which agent can write to the ticket database. A list of APIs cannot tell you that one was created by an unreviewed coding agent for a customer-facing assistant. Security needs to trace the path from service to agent, from agent to tool and data, and from each action to any new resource left behind.

That map must stay current. A team can add a tool, upload a new knowledge file, widen a database connection, or deploy another job after the pilot was first reviewed. Discovery needs to notice those changes and show both what an agent can do and what it did. Only then can security narrow a permission, remove a risky connection or file, stop an unsafe agent, and find the downstream assets that also need attention.

Knowing which AI apps employees use is the beginning of shadow AI discovery. The harder work is seeing what people and agents build inside those apps, what those creations connect to, and what they leave behind.

Connect with the Zenity team to learn more about the risk of Shadow AI within your organization.