AI agent discovery is the first of the four questions agent security must answer, and the one most teams get wrong, either by counting every service account as an agent or by missing the agents that never touch a SaaS admin console. This guide covers what counts as an agent, where agents hide in Google Workspace, AWS AgentCore, GitHub, Slack, Salesforce, Claude, ChatGPT and Cursor, what finds them, and why local processes, MCP config files and browser sessions need sensors rather than APIs. Strac discovers all of it into one inventory with an owner, sanctioned state and evidence on every row, then feeds it into permissions, activity and sensitive-data analysis.
Ask three people in your company how many AI agents are running and you will get three different numbers, all wrong in the same direction. The identity team counts service accounts. IT counts approved SaaS apps. Nobody counts the Claude Code session an engineer started on a laptop this morning, the Zapier flow that still signs into the CRM with a shared login, or the Cursor background agent that was handed a GitHub token three months ago and never revoked.
AI agent discovery is the work of producing one honest list: every AI agent and AI-enabled automation in the business, what each one runs as, who owns it, and whether anyone sanctioned it. It is the first of the four questions that AI agent security has to answer (identity, authorization, activity, data), and every later question inherits its errors. If the inventory is missing an agent, you cannot map its permissions, attribute its actions or join it to the sensitive data it can reach.
It is also the step most teams get wrong, in a specific way: they treat every non-human identity as an agent and end up with thousands of rows of noise, or they count only AI vendor OAuth grants and end up with a dozen rows of guesswork. This guide covers what counts as an agent, where agents hide and what finds them, why API-only discovery misses the fastest-growing kind, what a CISO sees in the first inventory meeting, and how to keep the number honest afterward.
A working definition: AI agent discovery is the continuous process of finding every actor in your environment that interprets instructions and chooses its own actions, then recording for each one the identity it acts through, the owner accountable for it, the sources that found it, and its sanctioned state.
Three words in that definition do most of the work.
Continuous. Agents are created by individual users in seconds. A one-time audit is stale before the slide deck is finished. Strac refreshes agent, app and principal inventories every 6 to 24 hours plus on demand, and polls activity feeds every few minutes where the provider supports it.
Actor. The unit of discovery is the thing that acts, which is different from the thing that is installed. One Claude OAuth client can serve many users and sessions, so discovery records the application once, the connection per user, and a specific agent session only when vendor, runtime or sensor evidence supports it. One client per agent undercounts; one token per agent overcounts.
Sanctioned state. An inventory that cannot distinguish the agents security approved from the ones it has never heard of is a list rather than an inventory. Its output is the same artifact a shadow AI program needs: a sanctioned list, an unsanctioned list, and a decision for everything on the second one.
What discovery is not: a permissions audit, an activity log or a data map. Those are the next three questions, each with its own confidence model. Collapsing them produces inventories that claim an agent "accessed payroll" when all anyone knows is that it held a scope that could have.
The most common inventory mistake comes from a reasonable instinct. Your identity tool has a list of non-human identities, many of them AI-adjacent, so the first draft of the agent inventory is "every NHI that touches an AI vendor." That inventory is wrong in both directions.
A CI bot that runs the same script on every commit is a non-human identity. It is not an agent. Neither is a nightly backup service account or an OAuth app that syncs calendar invites. None of them interpret instructions or choose actions, so none of them have the property that makes agents a distinct risk: a blast radius equal to every permission behind every credential the agent can borrow, which the code tells you nothing about.
Conversely, a Cowork session driving Alice's logged-in Salesforce tab is absolutely an agent, and it has no non-human identity at all. Salesforce sees Alice.
So the classification rule Strac applies: store two independent flags on every principal. is_non_human_identity says whether the principal is a human. is_agent says whether evidence shows AI or agent behavior. Neither implies the other. In a typical mid-size tenant the first flag is true for around 4,000 principals and the second for a couple of hundred, and the couple of hundred are where agent-grade controls belong.
What evidence sets is_agent, in order of strength:
.webp)
actor_is_agent=true and an agent_session_id. AgentCore runtimes are agents by definition. Salesforce Event Monitoring tags Agentforce traffic with BotId and BotSessionId, and MCP server traffic shows up as service=agentic-api-service.client_id belongs to Claude, ChatGPT or another known AI vendor, matched against a curated vendor registry with tenant-specific overrides.agent_confidence on every agent and leaves it low until evidence arrives.What never sets the flag on its own: a display name. "AI Assistant Prod" is not an agent because of the string in its name, and "data-sync-3" is not excluded because of its. Keyword matching on names is the fastest way to build an inventory nobody trusts. Strac attaches the evidence to the classification so a reviewer can disagree with it and see exactly what would change their mind.
Agents live wherever credentials and data live. Each provider exposes a different control-plane API for finding them, with different fidelity, and each has a blind spot that only a sensor on the endpoint, browser or MCP path can fill. This is the map Strac's discovery connectors are built against.
tokens.list per user (client_id, scopes); Reports API token audit (authorize, revoke, activity)client_id is a verified AI clientadmin.apps.approved.list, restricted.list, requests.list; admin.apps.permissions.list; Audit Logs app_installed, app_scopes_expanded, app_resources_grantedrepository_selection); enterprise audit log with actor_is_agent and agent_session_idListAgentRuntimes, GetAgentRuntime (roleArn, workloadIdentityArn); ListWorkloadIdentities; gateways and credential-provider metadataApiEvent with ConnectedAppID, BotId, BotSessionId, ServiceNameapplication_type; cloud-agent config; hooks and OpenTelemetry for runtime depth
Two design rules sit behind that table. First, Strac uses provider control-plane APIs and audit logs before building anything inline, because a proxy sees traffic and a control plane sees the grant that needs revoking. Second, every connector reports honest coverage. If a tenant's Salesforce edition lacks Event Monitoring, discovery says "not configured" for that capability. It never returns an empty result that looks like zero agents, and a partial snapshot degrades freshness rather than deleting identities.
The last three rows of that table are where most agent discovery tools, and most shadow AI detection tools, go blind. They are also where the fastest-growing class of agents lives, and where AI agent visibility is weakest in the companies we talk to.
A SaaS-posture or NHI tool calls each provider's admin API and enumerates OAuth grants, app installations, bot users and IAM roles. That covers identity patterns A through D well. It cannot see:
.env files, shell profiles and agent config directories. The endpoint secrets scan is what ties a key to a device, a user and the agent process that reads it.
This is why the browser, endpoint and MCP sensors Strac already deploys for AI DLP are the unfair advantage in agent discovery. They are optional evidence adapters into the same graph. The inventory works without them; with them, patterns E and F stop being invisible. For the techniques in more detail, see how to detect shadow AI and the comparison of shadow AI detection tools by the surfaces each can observe.
One rule on honesty: anything a sensor finds is labeled correlated rather than provider-native, with the confidence factors (overlap window, same tab, file lineage) shown so a reviewer can disagree. Weak attribution presented as fact is how inventories lose the trust of the people who have to act on them.
Strac deploys read-only. Connect Google Workspace, AWS, GitHub, Slack, Anthropic, OpenAI and Salesforce with discovery credentials only, and a small tenant's first inventory usually lands within the hour. The first review of that inventory is the most uncomfortable meeting of the quarter, and it tends to go the same way everywhere.
The headline numbers come first: 187 agents discovered, 41 unmanaged, 23 overprivileged, 17 that can reach sensitive data, 6 critical. Then someone asks where the 187 came from, and the answer by provider follows where credentials concentrate: Google Workspace 61, GitHub and Copilot 38, Slack 28, AWS AgentCore 23, Salesforce 15, Claude 11, ChatGPT 7, Cursor 4.
Then the room looks at the rows, and four categories show up in every first inventory we have seen:
Ownerless agents. An Agentforce case-triage bot with no owner recorded. A Slack app whose installer left the company. An IAM role created for a hackathon. Strac's rule, applied the same way every time: an agent with no accountable owner plus recent activity or a valid credential is a High finding. In a first inventory, that is often a quarter of the rows.
Stale agents with live credentials. No activity for 45 days, token still valid. Nobody is watching, nobody would notice if the credential were used, and the credential works. Nine of the 187 above.
Shared-identity agents. A Zapier lead-sync flow signing into the CRM with a team login. A computer-use agent running under an engineer's browser session. Twelve agents in that inventory use shared human identities, so every audit log in those systems attributes their actions to a person who did not perform them. Only sensors find this category, and it is a Medium or High finding on its own because the provider cannot revoke the agent without revoking the human.
Overprivileged agents. Write, delete or admin capability granted and never exercised in the policy window. The Claude Code session granted gmail.readonly alongside drive.readonly that has only ever called Drive. The Copilot agent with contents:write on twelve repos that has touched two. Twenty-three of the 187. This finding needs the authorization and activity questions too, but discovery is what makes it possible to ask.
What does not happen in a good first meeting: nobody argues about whether the number is real. Every row carries its discovery sources and evidence, so the conversation moves straight to who owns what. If the first hour is spent debating false positives, the inventory has already failed.
An agent without an owner cannot be sanctioned, cannot be remediated without a fight, and cannot be offboarded when its creator leaves. Resolving the owner is therefore part of discovery rather than a later governance chore, and how it is done depends on the identity pattern.
client_id and when.app_installed in Slack, the installation actor in GitHub, the creating admin for a Salesforce integration user). This is where ownership most often needs metadata, and where an identity connector such as Okta maps the installer to a current employee and manager.That last case is how the inventory stays honest. When discovery cannot resolve an owner with evidence, it does not guess from an email alias or a team name. It opens an owner request to the most likely candidate (the acting user, the installer's manager, the team that owns the connected resource) with a deadline. A governance policy with "owner required" turned on produces 41 owner requests on the first run against the inventory above. Unanswered requests escalate; answered ones update the record with the claim as evidence. Who should be accountable for which agent identity is covered in AI agent identity governance.
Once an owner exists, sanctioning becomes a decision rather than a mystery. Each agent carries a sanctioned_state, and the owner or reviewer picks from a bounded set of actions:
client_id; Slack restrict or uninstall)Exceptions with expiry deserve a sentence on their own. Every inventory accumulates "known, fine, ignore" rows. Without an expiry those rows are indistinguishable from neglect six months later. With one, the inventory re-asks the question on a schedule, which is the difference between a governance program and a spreadsheet. The operating framework is in AI agent governance, and the multi-business-unit version in enterprise AI agent governance.
"AI agent sprawl" is usually a feeling: the sense that there are more of these things every week, nobody knows how many, and somewhere among them are rogue AI agents nobody would notice. Discovery turns the feeling into a number, and a number can be managed.
Three metrics make sprawl measurable, and they belong on a monthly slide:
Keeping those numbers honest comes down to habits the product enforces:
With a stable set of agent IDs, each with an owner, an identity pattern and a sanctioned state, the other three questions become answerable:
Strac answers all four in one graph, Agent → Principal → Permissions → Resources → Sensitive data. The agent record that discovery creates is the one that carries the permission map, the activity timeline and the data reach; adding a sensor or connector enriches it rather than creating a second inventory to reconcile.
👉 Book a demo and we will run the agent inventory read-only against your Google Workspace or Slack tenant during the call, and show you the first ownerless agent before it ends.
AI agent discovery is the continuous process of finding every AI agent and AI-enabled automation in an organization, across SaaS, cloud, AI vendor platforms, workstations and browsers, and recording for each one the identity it acts through, its owner, the evidence that found it and whether it is sanctioned. It is the first of the four questions in AI agent security, ahead of authorization, activity and data, and the one the other three depend on.
An NHI inventory lists every service account, bot, API key and OAuth app, whether or not anything intelligent sits behind it. An AI agent inventory is the subset that interprets instructions and chooses actions, plus the agents that have no non-human identity at all because they borrow a human's session or login. Strac stores the two as separate flags on every principal; in most tenants a few percent of NHIs are agents, and some agents are not NHIs.
Shadow AI agents are agents running in the business that security never sanctioned and often never knew about: a local Claude Code or Cursor process on a laptop, an MCP server declared in a developer's config file, a Zapier flow signing into the CRM with a shared login, or a computer-use agent driving an employee's open browser tab. Most leave no footprint in any SaaS admin console, which is why they are found by endpoint and browser sensors rather than provider APIs.
Partly. Provider APIs find agents that hold an OAuth grant, an app installation, a bot user or an IAM role, which covers identity patterns A through D and most cloud and SaaS agents. They cannot find local agents, local MCP servers, browser-session agents or static credentials on a workstation. Strac's inventory works with API discovery alone and gets more complete when the browser, endpoint and MCP sensors are added, with each row showing which source found it.
By evidence, never by name. A provider that explicitly marks agent activity (GitHub's actor_is_agent, Salesforce's BotId, an AgentCore runtime) is the strongest signal; a verified AI vendor client_id on an OAuth grant is next; a sensor observing the agent process, MCP config or tool call is next. A display-name keyword is not evidence in either direction. Strac records an agent_confidence on every agent and leaves unknown classifications unknown rather than guessing.
At minimum: the agent and the vendor behind it, the owner, the identity pattern and the principal it runs as, the connected systems, the discovery sources that found it, first and last seen, sanctioned state, and attribution confidence. Once the other three questions are answered, the same record should also carry effective permissions, sensitive-data reach, the activity timeline and open findings, so the inventory row is the entry point to everything known about the agent.
.avif){kind=icon}
.gif)
