Shadow AI agents: how to discover and inventory the agents at work in your organization

What shadow AI agents are

Shadow AI agents are AI agents that run in your organization without appearing on any list that security, IT or compliance can see. Someone built one or switched it on to get work done. It holds real credentials and real access. Nobody signed off on it, and often nobody is named as its owner.

AI agent discovery is the practice of finding those agents from the evidence they leave behind, and keeping an inventory that stays accurate. To discover AI agents in your organization reliably, you need evidence from several systems, because each one sees only part of the picture. It is the first control in a program for AI agent security. You can't give an agent an identity, limit its access or keep an audit trail for it if you don't know it exists.

NIST's AI Risk Management Framework makes the same point in governance terms. Its GOVERN 1.6 subcategory reads: "Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities."

This page is the practitioner's how-to: sources, matching rules, inventory fields and a two-week plan. For the business view, including why surveys and sign-up forms miss agents, read Find the AI agents at work in your business.

Agent, AI feature or script: the agent loop test

Not everything that calls a model is an agent. Sort what you find before you count anything.

• AI feature. Code calls a model and shows the answer to a person. A tool that drafts marketing copy is one. It takes no action itself.
• Scripted AI call. Code calls a model on a fixed path, then does a fixed thing with the result. The model never chooses an action.
• Agent. The model chooses which tools to call. The program runs the tool and sends the result back to the model, which decides the next step. That cycle is the agent loop.

The loop leaves a signature you can test for. A request to the model includes tool definitions. The response asks for a tool call. The next request carries the tool result. If you see all three from the same process or identity, you have an agent. A model call alone only proves that something uses AI.

Two more categories help. Agents in development are agent code in a repository, not yet seen running. Tools are the Model Context Protocol (MCP) servers and APIs that agents connect to.

Keep the test honest. A scripted call that sends email based on model output can do as much harm as an agent. Classify by structure, then rank by what each item can reach.

Where agents leave evidence

No single system sees every agent. A platform knows its own agents but not what else they can reach. An identity provider knows what an account can do but not that an agent is using it. Combine sources.

Endpoint and MCP config files

Endpoint config files deserve attention, because they show agents running on laptops with a person's own access. Claude Desktop keeps MCP servers in claude_desktop_config.json, and the MCP documentation warns that a local server "runs with your user account permissions". Other clients use their own files. VS Code alone documents several locations as of October 2026. Scan for the paths you know, and expect the list to change.

Read what each entry launches, not just that it exists. A config entry names a command and its arguments, such as a package fetched at start-up or a folder the server may read. That tells you which tools the assistant has, which code runs on the device and what it can touch. Endpoint management or EDR tools that can collect files are a practical way to gather these configs at scale. Record each server as a tool, linked to the person whose machine runs it.

Reconciling declared and observed agents

Evidence falls into two groups. Declared evidence comes from systems where someone set an agent up: platform registries, IdP app registrations and code repositories. Observed evidence comes from what actually ran: model logs, network flows, host sensors and traces. Reconciliation matches the two, and each item lands in one of four states:

• Declared and observed. A confirmed agent. Assign an owner and verify its access.
• Declared, not observed. Dormant or still in development. Check whether it still needs its credentials, and retire it if abandoned.
• Observed, not declared. Shadow AI. Find the owner and triage by what it can reach.
• Conflicting. The evidence disagrees. A person decides.

Match on strong keys first. Start with the identity that made the call: a role ARN, an app's client ID or a SPIFFE ID. Then match the workload: pod, process or image digest. Then the code: repository and commit. Names are weak keys, because two teams can both run a "support-bot". When the only link between two records is a similar name, don't merge them automatically. Ask the likely owner, then record the decision and the evidence behind it.

Keep a confidence level on every entry: confirmed, probable or suspected. Confirmed means an agent loop was observed, or a registry entry matched runtime evidence. Report counts by confidence. A single number with no confidence level overstates what you know.

What an AI agent inventory entry should hold

Each entry should answer four questions: what it is and how sure you are, where it runs, who owns it, and what it can reach. A minimal record looks like this:

id: agt-0142
name: invoice-reconciler
category: custom agent      # platform | custom | shadow AI | AI feature | in development | tool
confidence: confirmed
evidence: [platform registry, model invocation log, repo commit 4f2a9c1]
runs_in: aws / finance-prod / ecs service reconciler
identities: [iam role invoice-reconciler]
reaches: [billing API refunds.create, billing API invoices.read]
acts_for: none              # or: the signed-in user
owner: finance-platform team
data_classes: [payment data]
first_seen: 2026-09-02
last_seen: 2026-10-27
flags: [broad access]

Keep the inventory about agents, not their content. Store that an agent exists and what it connects to. Don't store prompts, responses or the records agents handle. They add privacy risk and add little to discovery.

Record the model providers each agent uses, too. That tells you where data leaves the company, which is the first question in data loss prevention for AI agents.

Treat MCP servers and APIs as entries of their own, linked to the agents that use them. Then you can answer the reverse question during an incident: which agents could reach the billing API? See MCP security for what to check on each server.

Risk flags that set your priorities

Flags turn a long list into a work queue. Set them automatically from evidence and review them weekly.

• Shadow AI. No platform, project or owner accounts for it.
• No owner. Nobody is accountable. Often the builder left or changed teams.
• No identity. The agent has no credential of its own to hold it to account.
• Shared login. Several agents use one credential, so you can't tell who did what. OWASP lists this as NHI9 NHI Reuse in its Non-Human Identities Top 10.
• Broad access. More access than the job needs, such as an assistant that can send email as anyone.
• Acts for users without a delegation record. It uses people's own tokens, so logs blame the person.
• Unreviewed tools. It connects to MCP servers or plugins nobody approved.

In AgentFort's lab demo against Northwind, a simulated company, discovery found 14 entities. They included a summary script on a finance workstation calling a model that nothing accounts for (shadow AI) and a batch job with no identity.

Rank by what an agent can do, not by how it was built. A confirmed agent that can issue refunds outranks 10 AI features that draft text.

How to run a first AI agent inventory in two weeks

A first inventory needs read access and a few decisions, not new infrastructure.

1. Days 1–2: set scope and roles. Pick the cloud accounts, SaaS tenants and repositories in scope. Name one person to run the inventory and one to settle disputed ownership.
2. Days 2–4: pull declared evidence. Export agents from each platform registry. List IdP app registrations and OAuth grants with scopes that write data or send mail. Search repositories for agent frameworks, model SDKs and MCP configs.
3. Days 3–6: switch on observed evidence. Enable model-provider logging where it is off, and limit stored content where the provider allows it. Pull proxy logs for connections to AI services. Put host or pod sensors on a sample of clusters and servers.
4. Days 6–8: apply the agent loop test. Classify each item as agent, AI feature, scripted call, in development or tool.
5. Days 8–10: reconcile. Match declared to observed on strong keys. Send ambiguous matches to likely owners with a deadline.
6. Days 10–12: assign owners and flags. Every confirmed agent gets a named owner. Unowned agents go to the security lead's queue.
7. Days 12–14: report and decide. Publish counts by category and confidence. Take the 10 highest-risk agents and decide for each one: keep, fix or retire.

Expect gaps. Two weeks is enough to cover the systems you scanned. It tells you little about the systems you didn't, so list those openly in the report.

Keeping the AI agent inventory current

A one-off inventory starts to decay the day it ships. Teams create, change and abandon agents every week. Keep the evidence pipelines running. Treat each change as an event: a new agent, grant, MCP server, model provider or code version. Route events to the owner's queue, not only to a dashboard. Hook the inventory into processes you already run. When an employee leaves, reassign the agents they own. When procurement approves an AI product, expect its agents to appear. Re-run the agent loop test when a known AI feature starts asking for tools. Mark agents stale when they go unseen for a set period, and start offboarding. Ask owners to confirm their agents every quarter.

AI agent discovery checklist

• Define what counts as an agent with the agent loop test, and apply it the same way everywhere.
• Connect read-only to every platform where teams build agents.
• Pull identity provider grants, and flag those that can write data or send mail.
• Enable model-provider logging for caller identity and model metadata.
• Scan repositories and endpoints for agent frameworks and MCP config files.
• Match declared and observed evidence on identities and workloads, not names.
• Record a confidence level and the supporting evidence for every entry.
• Assign a named owner to every confirmed agent.
• Flag shadow AI, no owner, no identity, shared login and broad access.
• Review new and changed agents weekly, and have owners re-confirm quarterly.

How AgentFort handles this

AgentFort Discover looks for agents in five places. It checks where they're defined, where they get their brain (model calls) and where they get their hands (identities and permissions). It also checks where they're built and where they run. Read-only connectors cover Microsoft Copilot Studio, Microsoft Entra ID, Salesforce (Agentforce), AWS, Google Cloud and GitHub, plus cloud model logs, sidecar proxies and OpenTelemetry traces. An optional sensor on hosts and Kubernetes pods sees which process calls a model. When the model asks for tools and the results go back, the agent is confirmed down to pod and process. When Discover can't be sure two pieces of evidence are the same agent, it asks a person. It stores that an agent exists and what it connects to, never prompts, answers or data. See AgentFort Discover or request a demo.