Discover AI Agents: Find Shadow AI & Build an AI Agent Inventory (2026)

What Is an AI Agent?

An AI agent is an AI system that takes actions on a user's behalf. The distinction that matters for security is simple: a chatbot answers questions inside its own window; an agent reaches out into your systems and does things — reads files, runs commands, queries databases, calls APIs, and chains those actions together to complete a task with little or no human in the loop.

The canonical example is the coding agent. Tools like Cursor, GitHub Copilot, Claude Code, and Devin don't just suggest a line of code. They:

• Read your repositories — entire codebases, including config files, .env files, and anything secrets-scanning missed.
• Run commands in your terminal — installing packages, executing scripts, hitting build systems.
• Call APIs and tools — querying production databases, opening pull requests, posting to Slack, provisioning cloud resources.
• Act autonomously across multiple steps — a single prompt can trigger dozens of tool calls before a human reviews anything.

That is a software system with hands, operating with a developer's access. It is exactly the kind of thing security teams inventory for any other privileged process — and yet most organizations have no list of which coding agents are running, on whose machine, against which repos.

Coding agents are the sharpest example, but AI agents span a wider surface:

• AI assistants — ChatGPT, Claude, Gemini, and Microsoft Copilot, especially once employees connect them to email, Drive, calendars, or internal tools. The moment an assistant can read your Google Workspace or Microsoft 365 tenant, it stops being a chatbot and becomes an agent.
• MCP-connected agents — any AI client wired to a Model Context Protocol server. An MCP connector hands an agent live, standardized access to a SaaS app's API surface — a Salesforce MCP server or Slack MCP server turns a generic assistant into one that can read and act across your CRM or your channels.
• Custom and embedded agents — internally built agents on the OpenAI or Anthropic SDKs, custom GPTs, and the growing layer of AI features baked into the SaaS your team already pays for.

The common thread: every one of these agents can reach sensitive data — and once it does, that data leaves your control surface and enters a model's context window. That is why the first move in any AI agent governance program is figuring out which agents exist at all.

Why You Can't Govern What You Can't See

Every governance, protection, and audit control you want to apply to AI agents depends on one prerequisite: a complete, current list of the agents in your environment. You can't write a policy for an agent you don't know about. You can't redact the data flowing to a connector you've never seen. You can't produce audit evidence for activity you never logged. Discovery is the foundation the rest of governance stands on.

The problem is that AI agents are uniquely good at hiding. They proliferate through paths that never cross a procurement review or a security checklist:

• Shadow custom GPTs. An employee spins up a custom GPT and pastes in internal docs, support transcripts, or a customer list to "make it smarter." No ticket, no approval, no record.
• OAuth-connected AI apps. A single click on "Sign in with Google" or "Connect to Microsoft" grants a third-party AI app standing access to a user's mailbox, Drive, or calendar. The grant persists long after the employee forgets the tool existed.
• Self-wired MCP connectors. A developer adds an MCP server to Cursor or Claude Desktop in two minutes, pointing an agent at a production database or a SaaS app — with whatever scopes the connector requested.
• AI features inside existing SaaS. Vendors ship AI agents into tools you already use, often on by default, often reaching the same data the rest of the product does.

This is shadow AI agents: AI systems with real access to real data, spun up faster than any manual inventory can track, sitting entirely outside the security team's line of sight. Surveys across 2025 and 2026 consistently put the share of employees using AI tools their employer hasn't sanctioned well into the majority — and every unsanctioned tool that can take actions or reach data is an ungoverned agent. The gap between "AI tools security knows about" and "AI tools actually running" is where the next data-exposure incident lives.

Manual discovery cannot keep up. A spreadsheet of approved tools is stale the day after it's written. The only thing that works is continuous, automated discovery across every place an agent can appear — the browser, the desktop, the OAuth grant, the MCP connector, the SaaS audit log. That is what Strac does.

✨ How Strac Discovers AI Agents Across Every Endpoint

Strac discovers AI agents wherever they live, by watching every channel through which an agent gets created or reaches data — not just one. The result is a single map instead of five blind spots.

Strac discovers agents across these channels:

• Browser extension — which AI web apps employees use. Strac's browser layer sees when employees use ChatGPT, Claude, Gemini, custom GPTs, and any other AI web app — including the long tail of niche tools that never went through procurement. This is where most shadow AI assistants surface first.
• Endpoint agent — desktop AI apps. Coding agents and desktop AI clients (Cursor, Claude Desktop, GitHub Copilot, Devin runners, local LLM tools) run on the machine, not the browser. Strac's endpoint layer discovers the AI applications installed and active on company devices.
• MCP DLP — which MCP connectors are wired, and their scopes. Strac sees every MCP connector an agent has configured, which SaaS app or database it points at, and the exact scopes it was granted — so a Salesforce MCP connector with write access shows up differently from a read-only one.
• OAuth-grant inventory — AI apps with access to your tenant. Strac inventories the third-party AI apps that have been granted OAuth access to your Google Workspace, Microsoft 365, and Okta tenant — surfacing the "Sign in with Google" AI tools that quietly hold standing access to mailboxes, Drives, and calendars.
• SaaS audit logs — agent activity inside your apps. Strac reads the audit logs of your connected SaaS to catch AI agents acting through service accounts, API tokens, and embedded AI features that the other channels can't see directly.

No single channel catches every agent. A coding agent never shows up in the browser; an OAuth-connected AI app never installs on the desktop; an MCP connector's scopes don't appear in a SaaS audit log. Covering all five is how Strac produces a complete picture — the same multi-surface coverage that powers Strac's AI DLP and MCP DLP across the rest of the platform.

What an AI Agent Inventory Should Show

Discovery is only useful if the output is an inventory you can act on. A list of agent names is not enough — governance decisions depend on knowing what each agent can reach and how risky that is. A complete AI agent inventory maps, for every agent:

• Owner. Which employee or team spun it up and is accountable for it. Shadow agents have no named owner until discovery assigns one — and an un-owned agent with data access is the first thing to investigate.
• Data reach. Which systems and data the agent can touch — repositories, mailboxes, CRM objects, databases, file shares — derived from its OAuth scopes, MCP connector permissions, and observed activity. This is the difference between "an AI assistant someone uses" and "an AI assistant with read access to the entire executive mailbox."
• Volume of sensitive data flowing through it. Not just can it reach sensitive data, but how much actually flows — how many SSNs, card numbers, PHI records, secrets, and source-code files have passed through this agent. Volume is what separates a curiosity from a live exposure, and it's what lets you prioritize the agents that matter most.
• Risk score. A combined signal — scope breadth, sensitivity and volume of data reached, write vs. read access, sanctioned vs. shadow status — so the security team triages the riskiest agents first instead of drowning in a flat list.

With that inventory in hand, the rest of governance follows: you decide which agents to sanction, which to shut down, and which to wrap in policy. From there, Strac lets you protect AI agents — redacting, masking, and vaulting the sensitive data flowing to each one — and monitor AI agents continuously, so every tool call becomes audit evidence and new agents get caught the moment they appear. Discovery, protection, and monitoring are the three legs of the AI agent governance program, and discovery comes first.

🌶️ Spicy FAQs for Discovering AI Agents

What does it mean to "discover AI agents"?

Discovering AI agents means continuously finding every AI system in your organization that takes actions or reaches data on a user's behalf — coding agents (Cursor, GitHub Copilot, Claude Code, Devin), AI assistants connected to your tools (ChatGPT, Claude, Gemini, Microsoft Copilot), MCP-connected agents, and custom or embedded agents. The goal is a complete, current AI agent inventory rather than a stale spreadsheet of approved tools.

What's the difference between an AI agent and a chatbot?

A chatbot answers questions inside its own window. An AI agent reaches out into your systems and takes actions — it reads repos, runs commands, queries databases, and calls APIs, often chaining many steps with little human review. Coding agents like Claude Code and Cursor are the clearest example: they operate with a developer's access. The moment a chatbot is connected to your email, Drive, CRM, or codebase, it becomes an agent.

What are shadow AI agents?

Shadow AI agents are AI systems with real access to real data that exist outside the security team's visibility — employee-spun-up custom GPTs, OAuth-connected AI apps with standing access to your tenant, self-wired MCP connectors, and AI features turned on inside existing SaaS. They proliferate faster than any manual inventory can track, which is why automated, continuous discovery is the only thing that keeps up.

Why is discovery the first step in AI agent governance?

Because every other control depends on it. You can't write a policy for an agent you don't know about, redact data flowing to a connector you've never seen, or produce audit evidence for activity you never logged. Discovery is the prerequisite for protecting and monitoring AI agents — without a complete inventory, governance is guesswork.

How does Strac find AI agents across my organization?

Strac discovers agents across five channels: a browser extension (which AI web apps employees use), an endpoint agent (desktop AI apps like coding agents), MCP DLP (which MCP connectors are wired and their scopes), OAuth-grant inventory (AI apps granted access to your Google Workspace / Microsoft 365 / Okta tenant), and SaaS audit logs (agent activity inside your apps). No single channel catches every agent, so Strac covers all five and unifies them into one map.

Can Strac discover coding agents like Cursor and Claude Code?

Yes. Coding agents run on the desktop, not in the browser, so Strac's endpoint layer discovers the AI applications installed and active on company devices — Cursor, Claude Desktop, GitHub Copilot, Devin runners, and local LLM tools — and maps each to its owner and the repos and data it can reach.

What should an AI agent inventory include?

For every agent: the owner accountable for it, its data reach (which systems and data it can touch, derived from OAuth scopes and MCP permissions), the volume of sensitive data actually flowing through it, and a risk score that combines scope breadth, data sensitivity and volume, write-vs-read access, and sanctioned-vs-shadow status. The inventory is what lets you triage the riskiest agents first.

How is discovering AI agents different from traditional shadow-IT discovery?

Traditional shadow-IT discovery finds SaaS apps employees signed up for. AI agent discovery has to go further: it must see what each agent can do and reach — the actions it takes, the OAuth and MCP scopes it holds, and the volume of sensitive data flowing through it — because an AI agent's risk is defined by its access and activity, not just its presence.

What do I do after I've discovered my AI agents?

Use the inventory to decide which agents to sanction, shut down, or wrap in policy, then protect and monitor them. Strac lets you protect AI agents by redacting, masking, and vaulting the sensitive data flowing to each, and monitor AI agents continuously so every tool call becomes audit evidence and new agents are caught the moment they appear.

The Bottom Line

AI agents — coding agents reading your repos, assistants connected to your mailboxes, MCP connectors wired into your SaaS — are already running in your organization, most of them outside the security team's line of sight. You cannot govern, protect, or audit what you cannot see, which makes discovery the first and most important job of any AI agent governance program.

Strac discovers AI agents across every channel they appear in — browser, endpoint, MCP connectors, OAuth grants, and SaaS audit logs — and turns shadow AI into a unified inventory that maps each agent to its owner, its data reach, the volume of sensitive data flowing through it, and its risk. From there you can protect and monitor every agent on one control plane.

If shadow AI agents are spreading faster than your team can track them, book a 30-minute demo. We'll map the AI agents already running in your environment and show you the inventory live.

For the full program this sits inside, start with the AI agent governance pillar. For the data-protection layer underneath it, see MCP DLP and AI DLP.