How to Discover Shadow AI Agents in Your Enterprise

Thank you TraceForce for sponsoring this article.

“You cannot secure what you cannot see. In the era of agentic AI, the visibility gap is no longer a configuration problem — it is an architectural one.”

Introduction: The Invisible Workforce You Already Have

Something is running on your network right now that your SIEM doesn’t log, your DLP tool doesn’t intercept, and your asset inventory has never catalogued. It is not malware. It was installed by one of your own engineers — probably a high performer, probably with good intentions, probably solving a real problem faster than IT could respond to a ticket.

It is an AI agent.

More precisely, it is a shadow AI agent: an autonomous, tool-using, externally-communicating software process deployed without formal security review, without policy approval, and without any mechanism for your security team to observe what it is doing, what data it is touching, or what decisions it is making on behalf of your organization.

This is not a hypothetical threat. In a live demonstration shared recently, Varun Wadhwa — CTO of TraceForce — showed exactly this scenario playing out inside a standard developer laptop. An engineer was running Claude Code inside a VS Code dev container. The container had pre-configured MCP (Model Context Protocol) servers for GitHub and memory, and it was routing LLM calls through a company-hosted gateway. From the perspective of every legacy security tool in that environment, nothing unusual was happening. A developer was using their IDE. The container was just a container.

But from the perspective of an agentic security platform — TraceForce’s Scout Lite agent, auto-installed into the dev container at startup — the picture was completely different. There was an AI coding assistant with live tool access to a production GitHub repository. There was a memory MCP retaining context across sessions. There was outbound LLM traffic capable of carrying intellectual property, source code, credentials, or internal architecture details to an external inference endpoint. All of it is invisibleit invisible to the enterprise security stack. All of it running inside a sandboxed environment that was supposed to increase isolation.

That gap — between what your security tools see and what is actually executing in your environment — is the shadow AI agent problem. This article defines it precisely, explains where these agents appear, dissects why conventional tooling misses them, walks through a structured discovery workflow, and makes the case for why inventory is not just the first step but the foundational act of agentic AI security.

Defining Shadow AI Agents

The term “shadow IT” has existed for decades, referring broadly to software and services employees adopt outside of sanctioned IT channels. Shadow AI agents are a specific and considerably more dangerous subcategory, distinguished by three properties that make them categorically different from unauthorized SaaS tools or personal cloud storage accounts.

Autonomy. A shadow AI agent does not wait for a human to click a button. Once invoked — and in many architectures, once scheduled or event-triggered — it executes multi-step task chains independently. It reasons, plans, selects tools, calls APIs, reads and writes data, and decides when it has completed its objective. The human who deployed it may not observe any individual action; they see only the outcome.

Tool access. Modern AI agents are not chatbots. They operate through frameworks like the Model Context Protocol, LangChain tool definitions, OpenAI function calling, or custom harnesses that give them the ability to read and write files, execute code, query databases, call internal APIs, post to external services, and spawn sub-agents. Each of these capabilities is a potential data exfiltration path, a lateral movement vector, or a privilege escalation opportunity — depending on how the tool is scoped and what the agent is instructed to do.

External LLM dependency. Almost all current shadow AI agents send data to an external inference endpoint — whether that is OpenAI’s API, Anthropic’s API, Google Gemini, or a third-party wrapper service. This means that every prompt, every document chunk, every code snippet, and every system message passed through an unsanctioned agent is leaving the enterprise perimeter. Even when the response appears on a local screen, the inference happened in a data center the organization does not control, under a terms-of-service agreement the legal team has likely never reviewed for that use case.

Together, these three properties create an entity that is qualitatively different from previous shadow IT risks. A Dropbox account leaks what you put in it. A shadow AI agent leaks what it decides to put in it — autonomously, continuously, and invisibly.

For the purposes of a working security definition: a shadow AI agent is any autonomous, LLM-powered process with tool-calling capability that operates in an enterprise environment without having been inventoried, reviewed, and approved through a formal AI governance process.

Where Shadow AI Agents Appear

Figure 1. Five recurring locations where shadow AI agents proliferate. Every path egresses to an external LLM API; the result is invisible to legacy security tools.

Understanding where shadow AI agents proliferate is prerequisite to finding them. They do not appear randomly. They cluster in predictable locations, driven by the incentives and workflows of the people who deploy them.

Developer Environments and IDE Extensions

The most common spawning ground for shadow AI agents is the developer workstation. Tools like Claude Code, GitHub Copilot Workspace, Cursor, and Codeium have moved well beyond autocomplete. They now operate as full agentic loops — reading repository structure, planning implementation steps, writing and executing code, running tests, and committing changes. Many of these tools support MCP servers or plugin architectures that extend their reach into deployment pipelines, ticketing systems, and internal wikis.

The TraceForce demo illustrates this precisely. A developer running Claude Code inside a VS Code dev container had, without any malicious intent, created an agent with access to a production GitHub repository. The dev container pattern — increasingly standard at enterprises that want to standardize development environments — actually complicates discovery because it adds a layer of virtualization between the host endpoint monitoring tools and the running processes.

Workflow Automation Platforms

Platforms like n8n, Zapier, and Make have added native AI agent nodes that allow business users to build multi-step automated workflows without writing code. A marketing analyst might build an agent that monitors a Slack channel for customer feedback, summarizes it using an LLM, and posts a weekly digest to a Confluence page. A sales operations manager might build an agent that queries Salesforce, drafts follow-up emails with GPT-4o, and schedules them through the email client.

These agents run continuously, often on cloud infrastructure provisioned under a personal or unmanaged account rather than the enterprise tenant. They have access to whatever credentials the employee has pasted into the platform. They are, by construction, invisible to any endpoint monitoring tool because they run entirely outside the endpoint.

Agentic Frameworks Deployed by Data Science Teams

Python-based frameworks — LangChain, LlamaIndex, CrewAI, AutoGen, Haystack — have dramatically lowered the barrier to building custom multi-agent systems. A data science team that wants to automate model evaluation, competitive intelligence synthesis, or document processing can build a functional multi-agent pipeline in an afternoon. These pipelines often run as cron jobs, Kubernetes pods, or Lambda functions — infrastructure that may be provisioned under a personal or team AWS account rather than the enterprise account monitored by cloud security posture management tools.

This is where the MAESTRO framework’s Layer 2 (Data Operations) and Layer 3 (Agent Frameworks) risks crystallize. An agent reading from a data warehouse, chunking documents, embedding them, and sending them to an external vector database is performing a continuous, automated data exfiltration operation — even if the person who built it had entirely legitimate analytical goals.

MCP Servers in Sandboxed Environments

The TraceForce demo surfaced something important that many security teams have not yet absorbed: MCP servers change the threat surface of a sandboxed environment in ways that sandbox isolation alone does not address.

The entire premise of dev containers and sandboxed AI workspaces is that isolation reduces blast radius. If an agent misbehaves, it misbehaves inside the container. But an MCP server configured inside that container — for GitHub, for memory, for a file system, for a web browser — punches through the isolation boundary by design. That is what MCP servers are for: giving the agent reach into external systems. The sandbox contains the process but not the effects.

When the GitHub MCP server inside a dev container pushes a commit, that commit is real. When the memory MCP persists session context, that data is stored somewhere — possibly outside the container entirely. The sandbox model assumes isolation is the security primitive. MCP-enabled agents assume tool access is the functional primitive. These assumptions are in direct tension, and most enterprise security architectures have not yet resolved that tension.

Laptop-Level Agent Orchestrators

Some employees are running full agent orchestration stacks locally. Tools like Ollama combined with local MCP clients, or cloud-connected agents managed through custom harnesses, can create sophisticated agentic pipelines entirely on a developer’s laptop. These processes generate little to no network traffic that a DLP tool would flag — the LLM calls look like HTTPS requests to a known API endpoint, indistinguishable in traffic inspection from a developer querying documentation.

Why Legacy Tools Miss Shadow AI Agents

Figure 2. The dev-container blind spot. Host-level tools see a Docker daemon and an opaque HTTPS request; the agent, its MCP servers, and its outbound traffic live on the other side of the container boundary, where only a container-native discovery agent can enumerate them.

If you run an enterprise security program today, you have significant tooling investment. You likely have endpoint detection and response, a SIEM aggregating logs from dozens of sources, a cloud security posture management platform, a data loss prevention solution, network traffic analysis, and possibly a CASB. None of these tools were designed to detect, inventory, or govern AI agents. Here is why they fail systematically.

Process-Level Visibility Without Semantic Understanding

EDR tools excel at detecting anomalous process behavior — unexpected parent-child relationships, unsigned binaries, suspicious file modifications. But an AI agent running as a Python process invoked by a VS Code extension is not anomalous at the process level. It is a legitimate interpreter running a legitimate script. The EDR sees python3 agent_harness.py and has no basis for flagging it. It does not understand that this process is autonomously querying an LLM, calling a GitHub API, and making decisions about what code to commit.

Network Tools Lack LLM Traffic Context

DLP and network inspection tools look for patterns — SSNs in outbound traffic, credit card numbers, known malware signatures. LLM API calls are HTTPS POST requests to endpoints like api.anthropic.com or api.openai.com. The content of these requests — the prompts, the context windows, the tool call arguments — is encrypted. A network inspection tool sees: HTTPS POST to api.anthropic.com, a small encrypted payload, 200 OK response. It cannot see that the payload contained a proprietary customer contract, a database schema, or an internal architecture diagram that a developer fed into the agent’s context.

Even if TLS inspection is deployed, the LLM API call payload is structured JSON, not a pattern the DLP tool has been trained to flag. The prompt “Here is our Q3 customer list, help me draft follow-up emails” followed by a CSV dump of customer data does not match any DLP signature. It is just text.

CASB Coverage Gaps for Agent-to-API Traffic

Cloud Access Security Brokers were designed for SaaS governance — identifying when employees are using unsanctioned cloud applications through browser traffic. AI agents do not use browsers. They call APIs programmatically, often from backend infrastructure or local processes that route traffic outside browser proxies. The CASB never sees the traffic.

Even where CASB tools have added AI-specific policies, they typically operate at the application layer — blocking access to ChatGPT via the browser — rather than the API layer where most agentic traffic flows.

Container and Sandbox Blind Spots

As the TraceForce demo illustrated directly, dev containers are a specific blind spot. Endpoint monitoring tools installed at the OS level on a developer’s laptop typically cannot observe processes running inside a Docker container. The container’s process namespace is isolated from the host. Unless a monitoring agent is also installed inside the container — which Scout Lite does automatically — the host-level EDR sees only the Docker daemon, not the Claude Code process, not the MCP servers, not the tool calls.

This is not a misconfiguration. It is the intended behavior of container isolation. The security assumption is that the container is itself a trust boundary. But that assumption does not hold when the container’s explicit purpose is to give an AI agent reach into external systems.

No Schema for Agentic Artifacts

Legacy security tools have schemas for what they monitor: processes, file hashes, network connections, user authentication events, API calls to known services. They have no schema for the concepts that matter in agentic security: which agents are running, what MCP servers they have loaded, what tools are in scope, what their system prompt says, what data has passed through their context window, and what actions they have taken autonomously.

This is not a gap that can be patched with a new signature or a new DLP rule. It requires a fundamentally different monitoring primitive — one designed around the agent as the unit of observation rather than the process, the file, or the network packet.

A Discovery Workflow for Shadow AI Agents

Figure 3. Five-phase discovery workflow. Each phase adds a dimension of agent visibility; together they produce the Agent Bill of Materials on which all subsequent controls depend.

Given that legacy tools fail systematically, enterprises need a purpose-built discovery workflow. The following five-phase approach draws on the MAESTRO framework’s layered threat model and reflects the operational patterns emerging from platforms like TraceForce.

Phase 1: Endpoint Enumeration with Agentic Awareness

The starting point is the endpoint, because most shadow AI agents begin as local installations. Deploying a lightweight agent — analogous to Scout at the host level — that specifically enumerates AI-relevant artifacts is the first step. This means inventorying installed packages that match known agentic frameworks (langchain, crewai, autogen, anthropic, openai, litellm, and their variants), IDE extensions with agent capabilities, local LLM runtimes like Ollama, and configuration files that reference MCP server definitions.

The goal at this phase is not detection of malicious behavior. It is census: building a complete map of what agentic tooling exists in the environment before asking any questions about whether it is authorized.

Phase 2: Container and Sandbox Enumeration

Phase 1 enumerates the host. Phase 2 goes inside the containers. This requires a container-native monitoring approach — exactly what Scout Lite demonstrated in the TraceForce video. When a dev container starts, a lightweight discovery process should automatically execute inside it, enumerating running processes, loaded MCP servers, active LLM connections, and configured tool sets.

This phase surfaces the class of shadow agents that are otherwise completely invisible: agents running inside dev containers, Kubernetes pods, GitHub Codespaces, and cloud-hosted sandbox environments. The key implementation insight from the TraceForce demo is that MDM-enforced installation at container startup — not post-hoc scanning — is the only reliable mechanism. Agents that have already run and exited before a scan executes are gone. Continuous discovery from within the container is the only way to maintain current-state awareness.

Phase 3: Network Traffic Baseline and LLM API Fingerprinting

While encrypted LLM payload content cannot be inspected without TLS termination, the pattern of LLM API traffic is highly distinctive and can be baselined. LLM API calls have characteristic request sizes, response cadences, and endpoint fingerprints. A process making regular HTTPS calls to api.anthropic.com, api.openai.com, or generativelanguage.googleapis.com is almost certainly an AI agent or application. Correlating these network observations with the process inventory from Phases 1 and 2 closes the loop between “what is running” and “what is calling out.”

This phase also surfaces cloud-based agents — n8n instances, serverless functions, and automation platforms — through their outbound traffic signatures, even when the processes themselves are not on a managed endpoint.

Phase 4: Identity and Credential Correlation

Shadow AI agents do not operate in a credential vacuum. They use API keys, OAuth tokens, service account credentials, and sometimes human employee credentials stored in .env files, secrets managers, or hard-coded in scripts. Phase 4 correlates the agent inventory from Phases 1 through 3 with the organization’s identity infrastructure — secrets management systems, OAuth grant logs, API key issuance records, and service account inventories.

The goal is to answer: whose credentials is this agent operating under? If an agent is acting with a developer’s GitHub token, it is effectively that developer — but without the developer’s real-time judgment, and potentially running long after the developer has moved to a different role or left the organization. Orphaned credentials in shadow agents are a significant persistence risk that identity teams routinely miss precisely because they are not looking for agentic processes as a credential consumer category.

Phase 5: Behavioral Baselining and Anomaly Detection

The preceding four phases produce a static inventory: what agents exist, what tools they have, whose credentials they use. Phase 5 introduces temporal observation — watching agents behave over time to establish what normal looks like and detect deviations.

Behavioral baselining for AI agents is meaningfully different from traditional UBA because the variability of LLM-driven behavior is high by design. An agent that one day summarizes documents and the next day starts querying a database it has never accessed before may be following legitimate new instructions — or may have been subjected to prompt injection. Distinguishing these requires a baseline of normal tool call patterns, normal data access scopes, and normal outbound traffic volumes, then alerting on statistically significant deviations.

This is where Simon Willison’s Lethal Trifecta becomes operationally relevant: an agent that combines access to private data, exposure to untrusted content, and the ability to communicate externally is, in his framing, the highest-risk profile. The CSA MAESTRO framework arrives at a similar conclusion through its layered threat model — agents that span Layer 2 (Data Operations) and Layer 7 (Agent Ecosystem) with credentialed tool access concentrate the same combination of risks. Phase 5 should weight anomaly scores accordingly, treating that combination as a priority investigation target regardless of whether individual signals appear benign in isolation.

Why Inventory Is the Foundation of Agentic AI Security

Every mature security discipline begins with inventory. You cannot patch what you have not catalogued. You cannot govern what you have not enumerated. You cannot respond to an incident involving an asset you did not know existed. These principles have been true for vulnerability management, for cloud security, for endpoint protection, and for identity governance. They are true — with considerably higher stakes — for agentic AI.

The stakes are higher for a specific structural reason: AI agents have agency. A misconfigured cloud storage bucket sits there, passively leaking data to whoever discovers it. A shadow AI agent actively makes decisions, takes actions, calls tools, and generates effects in external systems — continuously, autonomously, and at the speed of software. The window between “agent starts running” and “agent causes a security incident” can be measured in seconds. The window between “agent causes an incident” and “security team discovers the agent exists” can be measured in months, if discovery happens at all without purpose-built tooling.

Inventory solves this by compressing that second window toward zero. If you know what agents are running before something goes wrong, you can apply controls — Intent-Based Access Control policies, tool scope restrictions, output monitoring, rate limits, human-in-the-loop checkpoints — before the incident rather than in response to it. That shift from reactive to proactive is what separates security programs that govern agentic AI from those that simply hope they are not in the next breach report.

The TraceForce demo makes this concrete. The visibility Varun demonstrated — Claude Code discovered, GitHub and memory MCPs enumerated, all scoped to a specific sandbox — is not the end state of agentic AI security. It is the precondition for everything else. From that inventory, an enterprise can ask: is this agent authorized? Is its MCP scope consistent with policy? Is the credential it is using still valid and appropriately scoped? Is it routing through the approved LLM gateway or calling an external endpoint directly? Has its behavior deviated from its established baseline?

None of those questions can be asked without the inventory. And none of the controls — MCP allowlisting, LLM gateway routing, output inspection, IBAC enforcement — can be applied to an agent you do not know exists.

There is also a compliance dimension that is maturing rapidly. Emerging AI governance frameworks — the EU AI Act, NIST AI RMF, ISO 42001, and the CSA’s AI Safety guidelines — are converging on a shared expectation: organizations must be able to demonstrate awareness and control of the AI systems they operate. “We did not know our employees were running that agent” is not a compliance posture. It is an admission of a governance gap that regulators and auditors will increasingly treat as a control failure.

The analogy to software supply chain security is instructive. A decade ago, most enterprises had no systematic visibility into the open-source components in their software. The Log4Shell vulnerability in 2021 exposed how catastrophic that blind spot could be — organizations could not even answer “do we use Log4j?” let alone “where and in what version?” The response was SBOM: Software Bill of Materials — mandated, systematic inventory of software components as the foundation of supply chain security governance.

We are at the equivalent inflection point for agentic AI. The question “what AI agents are running in our environment?” is today unanswerable at most enterprises. The question will be asked — by boards, by regulators, by incident responders, by cyber insurers — with increasing urgency. An Agent Bill of Materials is not yet an industry-standard term, but the underlying requirement is already taking shape in governance frameworks and customer security questionnaires. Organizations that build discovery capability now will have the foundation in place when that requirement crystallizes. Organizations that do not will face the agentic equivalent of Log4Shell: a pervasive, invisible risk that they cannot scope, cannot patch, and cannot explain.

Conclusion: Discovery Is Not Optional

Shadow AI agents are not a future risk. They are present, proliferating, and operating in your environment right now — in dev containers, in workflow automation platforms, in data science pipelines, in IDE extensions running on managed laptops. They escape every legacy security tool you have deployed, because those tools were built for a world in which software did what it was told, when it was told, by a human who was watching.

That world no longer describes your environment.

Discovery is the act of making the invisible visible. It requires purpose-built tooling — lightweight host agents, container-native monitoring, network traffic fingerprinting, identity correlation, and behavioral baselining — deployed systematically across every environment where agentic AI might run. The TraceForce approach of enforcing Scout Lite at container startup via MDM is one concrete instantiation of this. The principle it embodies — that discovery must be continuous, automatic, and native to the execution environment rather than bolted on from the outside — is the architectural insight that every enterprise security team needs to internalize.

Get the inventory. Everything else depends on it.