Shadow AI discovery, without asking anyone to register first
Network monitoring misses in-house agents calling provider APIs from your own infrastructure. Where shadow AI actually shows up, and what a first-day discovery report can tell you before any policy is switched on.
The problem
What this is actually about
Discovery built around egress to known AI domains finds the chatbots and misses the agents. In-house agents call provider APIs from inside your own infrastructure, on your own addresses, using credentials your own identity provider issued — which looks like ordinary application traffic because that is what it is.
Shadow agents also accumulate rather than appear. A prototype gets a service account, keeps running after its author changes team, and nobody revokes it because nobody knows it exists. The result is an unowned identity with standing access and no review date, and the only thing that finds it is looking somewhere other than the network.
What the platform does about it
Read from the product architecture rather than written here, so this page cannot promise something no module ships.
What AI agents exist here?
- Connectors across AI platforms, cloud, identity providers, source control, enterprise applications and infrastructure
- Shadow agent discovery from model API traffic, AI keys, MCP configuration, SDK dependencies and automation credentials
- An inventory record per agent: owner, purpose, model, framework, tools, MCP servers, data sources, permissions and secrets
- Ten lifecycle statuses from Discovered through Quarantined and Retired
What is this agent built from, and what breaks if a piece does?
- An AIBOM per agent: model, framework, tools, MCP servers, databases and packages
- Dependency monitoring for vulnerabilities, compromised packages, revoked certificates, deprecated APIs and model retirement
- Blast radius from any one dependency to the agents, applications and departments that rely on it
Which non-human identities exist, and what are they holding?
- Read-only discovery across Entra, AWS, Google Cloud, Kubernetes, GitHub and databases, so onboarding never starts by asking for write access to an identity provider
- A graph rather than a list: owner to agent to workload identity to credential to resource, each link searchable
- A credential inventory that separates short-lived and federated credentials from long-lived bearer secrets, and says when each last rotated
- Effective permissions computed from roles, groups and resource policies together, rather than the assigned roles a console happens to show
- Least-privilege analysis against observed use, so an identity granted 132 actions and using 17 can be right-sized on evidence
- Findings that persist rather than pass: dormant, ownerless, overprivileged, shared, and credential expiring
- Toxic permission combinations and segregation-of-duties rules that only exist across identities, never within one
- A migration path off static secrets — federation first, then credentials brokered per action and expired after it
What it leaves behind
The artefacts these modules produce. Evidence generated by a decision, rather than assembled for an audit afterwards.
- A first-day discovery report naming agents nobody had registered
- An unregistered-agent alert with provider, data reach and risk
- An exportable bill of materials per agent
- An impact list the moment a dependency is compromised
- A count of long-lived credentials, and which workloads could stop using them
- A blast radius per credential: what it reaches, and which agents depend on it
- An ownership figure an auditor can check, with the gap named
See it working
Every claim above has somewhere on this site you can go and check it.
- Where discovery looks
Model platform accounts, identity providers, cloud workloads, source repositories and tool registries.
- What it returns
A fleet including agents at Discovered status — found, not registered, and ranked anyway.
- What an agent is built from
The dependency graph behind each agent, and what else relies on the same component.
Common questions
- How do you detect shadow AI that never leaves your network?
- By looking at the artefacts rather than the traffic: which model platform keys exist and who created them, which service accounts automation was given, which cloud functions invoke model endpoints, which repositories import agent frameworks, and which MCP servers grant new capability.
- Should we ban unapproved AI tools once we find them?
- Bans usually relocate the behaviour to personal devices where there is no visibility at all. Inventory without penalty, assign an accountable owner, remove standing privilege from anything unowned, and make the sanctioned path faster than the shadow one.
- Does a discovered agent cost anything to govern?
- No. Metering is on protected actions, never on discovered agents — charging per discovered agent would give a customer a reason to hide the objects the product exists to reveal.