Shadow IT was about applications nobody approved. Shadow AI is usually described the same way — copilots, chat tools and agents adopted without review — and the reflex response is the same: block the domains, publish a policy, buy a gateway. It does not work, for a reason that is worth being precise about.
Agents do not arrive as applications
A SaaS app announces itself: a login page, a subscription, a browser tab. An agent arrives as a set of relationships. A developer installs a coding agent and grants it access to a repository. A product manager connects an assistant to the company’s document store with an OAuth consent. An operations engineer gives a workflow agent a cloud role so it can tidy up unused resources. None of these look like a new application from the network’s point of view. All of them look like new identities from the identity layer’s point of view:
- a new OAuth grant with broad scopes on a SaaS tenant,
- a new service principal or API key created for “the bot”,
- a new tool binding — an MCP server, a function, a webhook — that turns the agent’s text into actions,
- a new delegation: the agent acting with a person’s authority, or with another agent’s.
That is why we say shadow AI is an identity problem. The thing you can see, and therefore govern, is the identity, the credential, the grant and the tool. Blocking a list of AI domains governs none of them.
Why the gateway is not enough
AI gateways and guardrails are useful for what they see: prompts and completions. They do not see the OAuth consent granted directly in a SaaS admin console, the service account created in a cloud account the gateway never touches, or the agent that talks to an internal API. More importantly, even when an agent does pass through a gateway, the gateway is asked the wrong question. It can judge whether a prompt looks dangerous. It cannot judge whether this identity should perform this action on this resource with this authority — because it does not know the identity’s owner, its effective access or the blast radius of the resource.
The model can request an action. Something outside the model has to decide, and that something needs identity context.
What discovery looks like when you treat it as identity
If agents are identities, you find them the way you find any non-human identity — by reading the systems that issue authority, not by sniffing traffic:
| Where to look | What reveals an agent |
|---|---|
| Identity providers and SaaS admin consoles | OAuth applications with read/write scopes on mail, files, repositories or CRM data; consents granted by individuals |
| Cloud IAM | Roles and service accounts whose names, tags or trust policies reference assistants, bots, copilots or orchestration frameworks |
| Source control | Repository apps, deploy keys and workflow files that invoke coding agents or model APIs |
| Secrets managers and CI variables | Keys for model providers stored next to cloud credentials |
| MCP and tool configuration | Server manifests and tool registries on developer machines and in shared environments |
| Chat platforms | Bot users, app installations and the people who installed them |
Each of these produces an identity with a credential, an owner candidate and a set of permissions. That is exactly the shape the rest of your non-human identity inventory already has. Shadow AI stops being a separate program and becomes a classification inside the one you already run.
The questions that matter once you have found them
Discovery is the beginning. For each agent identity, the governance questions are the ones you would ask of any powerful service account, plus a few that are specific to agents:
- Who owns it, and do they know? Many OAuth consents are granted by someone trying a tool for an afternoon. Ownership is frequently a surprise to the owner.
- What can it actually reach? Effective access, evaluated — not the scope list on the consent screen.
- Which tools can it call? A tool is a capability with its own identity and provenance. An unknown tool is an unknown dependency.
- On whose behalf does it act? Delegated authority is the normal case for agents, which makes confused-deputy problems the normal failure.
- What has it actually done? Without action-level evidence, every other answer is a belief.
Govern, don’t just block
None of this means “allow everything”. It means governing at the layer where agents are visible and controllable. Give sanctioned agents a governed identity with an owner and scoped credentials, so the sanctioned path is easier than the shadow one. Discover the unsanctioned ones through the identity layer, attribute them, and decide — keep with an owner, scope down, or revoke — with evidence attached. And plan for the action layer: the agents that matter most are the ones that can change production, move money or touch customer data, and those actions will eventually need an authorization decision made outside the model.
At Trustivan, the identity graph, agent profiles, agent ownership findings and runtime action authorization are available today. Agent discovery is not built, by design: no connector discovers an agent, and no screen registers one. We say that plainly because the architecture has to be right before the product claims are. The one claim we will make now: if you cannot see your agents in your identity inventory, you cannot see your agents.