A developer installs a coding-agent extension that calls their cloud credentials. A marketing operator wires up an n8n workflow that drives an LLM against the customer database. A vendor's SaaS quietly adds an agentic feature in last month's release notes. Each of these is an agent that touches production systems, and none of them went through the runtime review that a platform team's deployed agents went through.

The agents the platform team deployed under change control are the easy part of the security problem. The harder part is the agents nobody on the platform team knows exist.

This is the shadow agent inventory problem. It is the agentic version of shadow IT, with two properties that make it worse than the generalized version: the agents act faster than the discovery process the security team is used to running, and they reach data through credentials the security team already approved for other purposes. An agent nobody knows exists has unmeasurable discovery lag — every action it takes is discovered never, or by accident.

Where shadow agents come from#

A taxonomy of the common sources:

Developer-installed coding agents. Claude Code, Cursor, Copilot, and the agentic features in JetBrains, VS Code, Vim plugins, and CLI tools. Each runs under the developer's credentials by default. Each can read source code, environment variables, secrets in the repository, and SSH keys on the developer's machine. The security team's standard inventory of "what tools have access to production code" rarely covers the model-driven extensions a developer added last week.
No-code workflow tools. n8n, Zapier, Make, Workato, and the agentic LLM nodes inside Salesforce Flow, ServiceNow Now Assist, HubSpot, and Workday. A non-engineering operator wires up an LLM call against a data source the operator has access to. The LLM calls run under the operator's identity or the integration's service account; either way, the LLM now has a path to enterprise data.
MCP servers a developer installed. A Model Context Protocol server provides tools an agent can call. Developers install MCP servers the way they install npm packages — locally, often from public registries with no security review. An MCP server that bridges the developer's GitHub credential to a public agent is a path the security team hasn't audited.
Vendor SaaS that added agentic features. A CRM, an analytics platform, a customer-support tool, or a developer-platform vendor announces in a release note that their product now has an AI agent. The agent runs inside the vendor's environment but acts on your data through the integration the vendor already has. The integration was approved years ago; the agent is new.
Ad-hoc scripts. A developer wrote a Python script that calls an LLM API on a cron schedule. The script reads from a database the developer has access to and writes to a Slack channel. The script is in the developer's home directory on a shared workstation; the security team has no record of its existence.

Each of these sources produces agents that the security team's catalog, policy gate, and audit log all miss. They're not malicious; they're the work of people doing their jobs faster.

Why this is worse than shadow IT#

Generalized shadow IT — a SaaS tool an employee signed up for without going through procurement — has well-understood discovery patterns. The IT team monitors expense reports, DNS traffic, SSO logs, and email signatures for unfamiliar vendors. The detection latency is days to weeks; the response is to onboard or block.

Shadow agents move faster and reach further. A coding agent installed in the morning is reading source code by lunch. An n8n workflow wired up in an afternoon is querying the customer database by end of day. The window between installation and material impact is measured in hours, not weeks. By the time the IT team's monthly inventory review catches the agent, the agent has been active long enough that the security question is no longer "should this exist" but "what has it already done."

The reach question is the second amplifier. A SaaS tool that an employee signed up for outside procurement gets the employee's data into the SaaS. A shadow agent gets the employee's credentials applied to the LLM's decisions. The data the agent can reach is the data the employee can reach, which in most enterprises is much more than the data the employee actually uses. Shadow agents inherit the broad credential grants that "give the user access to do their job" expanded over years.

Four discovery surfaces#

Where to look:

Network egress. Outbound traffic to known LLM API endpoints (Anthropic, OpenAI, Google AI, Bedrock, Azure OpenAI) and the MCP-related ports a local agent uses to reach a tool server. The signal is high: agents have to call an LLM to be agents. The cost is that most enterprises have legitimate LLM traffic for documented agents, so the signal-to-noise on unfamiliar traffic depends on knowing what the documented set is.
Code repositories. Source code that imports an agent SDK (LangChain, LlamaIndex, Bedrock Agents, Vercel AI SDK), MCP client libraries, or that constructs prompts and posts them to an LLM API endpoint. Code search across the organization's GitHub or GitLab catches scripts and notebooks that LLM-related repositories don't appear in.
Identity provider logs. Anomalous token usage patterns. Service accounts whose access pattern changed in the last quarter — broader resource reach, shorter time between calls, different time-of-day distribution — are signals that a new automated client may have appeared. Tokens being minted at machine-rate by a principal whose previous pattern was human-rate is a strong signal.
Cloud control plane. New IAM roles in the last 90 days, new function deployments, new container images that include LLM-related dependencies. The cloud control plane is the system of record for what's running; an agent that runs in your cloud appears there.

These four surfaces are the ones the production discovery tools in 2026 instrument. Astrix Security's Agent Control Plane, announced at RSAC 2026, builds an identity graph that maps the operator-to-agent-to-resource relationships at the identity layer; Geordie AI, which won the RSAC 2026 Innovation Sandbox, fingerprints agents across code, cloud, and endpoints. Both are inventory-first products: they answer "what agents do we have" before they answer "how do we govern them."

What discovery doesn't catch#

Three classes of agents are hard to discover by these surfaces:

Vendor-side agents. A SaaS vendor that added an agent inside their environment doesn't generate any signal in your network egress, your code, your identity provider, or your cloud control plane. The agent is on the vendor's side of the integration. Discovery here depends on tracking the vendor's release notes and reviewing the integration the vendor has — both manual processes, with detection latency tied to the vendor's communications.
Agents using personal credentials. A developer who pasted their personal API key for a coding agent into their IDE has produced an agent that doesn't show up in the company's identity provider logs. The agent runs under the developer's personal identity at the LLM provider; the company-side identity logs see only the legitimate access pattern of the developer. Discovery here depends on endpoint instrumentation — what the developer's machine actually does — which most enterprises only deploy on managed devices.
Multi-step processes that don't look like agents. An n8n workflow that does five deterministic steps and one LLM call may not register as an agent in a discovery tool's heuristics. The LLM call is one node in a workflow; the workflow as a whole is the agent. Discovery tools that look for "an LLM with tools in a loop" miss the "an LLM with tools in a workflow."

Discovery catches a substantial fraction of shadow agents and misses the three classes above. The right pattern is to combine discovery with deployment-side controls — make it easy to deploy agents through the supported runtime, so the alternative paths become rare by attrition.

What you do with what discovery finds#

A discovered agent isn't automatically a problem. The three things to determine for each:

What can it reach? The credential it's using maps to a permission set; the permission set maps to the data and the systems within reach. The first question of governance is whether the reach is appropriate.
What is it being used for? A coding agent on a developer's machine that touches your source code is a different risk profile from a marketing-ops agent that touches the customer database. The right control set follows from what the agent is used for.
Who is responsible for it? Shadow agents often have no nominal owner — the person who installed the extension might have left, the workflow might have been built by someone now in a different role. Assigning an owner is the first governance step; the owner is who the policy questions get addressed to.

A useful response posture: tag every discovered agent with these three answers, route the agent to the right governance lane (deprecate, migrate to the supported runtime, document and accept), and rerun discovery on a quarterly cadence.

The reference architecture is inventory-first#

The 2026 architectural pattern that's converging is inventory-first: the agent control plane begins by discovering agents that already exist, then progressively migrates them onto the runtime's identity and policy surface. The migration is opt-in for the agent's owner; the discovery is continuous and operates whether the owner participates or not. Astrix's Agent Control Plane and Microsoft's Agent Governance Toolkit both fit this shape; the Microsoft toolkit is open-source (Microsoft blog) and provides a useful reference for what the discovery-plus-runtime architecture looks like in practice.

The deployment-side control plane that the rest of this blog has described — identity, policy, audit, containment — is the runtime that discovered agents are migrated onto. Discovery is the entry; the runtime is what the discovered agents are governed by once they've been migrated.

Deixic ships the runtime side. Discovery integrations are part of the deployment posture; the runtime accepts agents that have been discovered and onboarded, regardless of which discovery tool surfaced them. See What you can do for the runtime surfaces and Trust for the data posture during onboarding.