TL;DR: AI agents are proliferating inside SaaS tools and autonomous workflows faster than identity teams can provision, review, or even detect them, leaving shadow agents outside conventional IdP, inventory, and access governance processes, according to AuthMind. The core problem is that existing identity controls assume an agent will be registered before it matters, but many now appear only in network traffic and runtime behaviour.
At a glance
What this is: This is an analysis of how shadow AI agents evade conventional identity discovery and why network-level observation is becoming necessary to find them.
Why it matters: It matters because IAM, NHI, and governance programmes built around provisioning records and IdP logs will miss AI identities that are created in SaaS tools, by users, or by other agents.
👉 Read AuthMind's analysis of shadow AI agent discovery and runtime visibility
Context
Shadow AI agent discovery is the problem of finding AI identities that exist and act inside an environment without being properly registered in identity systems. The article argues that many agents are now created with almost no friction, which makes classic provisioning-led governance too slow to see them.
For identity teams, the issue is not only inventory accuracy. It is that AI agents can arise through SaaS integrations, personal accounts, and delegated workflows, then operate under a human session or create new agents at runtime. That breaks the assumptions behind conventional IAM visibility and forces practitioners to think about discovery, classification, and ownership together.
Key questions
Q: How should teams discover AI agents that never appear in the IdP?
A: Use continuous runtime observation instead of relying on provisioning events alone. Network traffic, model communication, and east-west activity can reveal agents that SaaS tools, users, or other agents create without a directory object. The key is to treat discovery as a behavioural problem, not an inventory synchronisation task.
Q: Why do provisioning records fail to show shadow AI agents?
A: Provisioning records only show what was intentionally registered, while shadow AI agents may be created inside SaaS platforms, through personal accounts, or by other agents at runtime. If your governance model assumes every agent leaves a provisioning trail, it will miss the identities that matter most.
Q: What do security teams get wrong about agent inventory and ownership?
A: They often assume that once an agent is found, a single inventory record is enough. In practice, you also need behavioural classification, accountable ownership, and lifecycle tracking, because different agent types create different access and secrecy risks across the environment.
Q: How should organisations govern autonomous agents differently from copilots?
A: Autonomous agents need stronger oversight because they can call tools, retrieve secrets, and generate sub-agents without the same session-bound limits as a copilot. Governance should reflect that difference in monitoring, approval, and scope controls rather than using one generic policy for every AI capability.
Technical breakdown
Why provisioning records miss shadow AI agents
Conventional identity tooling is built to observe what has been registered, provisioned, or linked to an IdP. Shadow AI agents often do not pass through those steps. They may be enabled directly in SaaS platforms, launched through personal credentials, or created by other agentic workflows that never emit a clean identity event. That means the control plane sees only partial truth, while the runtime reality exists elsewhere. Discovery therefore shifts from static inventory to continuous observation of actual communications and behaviour across the environment.
Practical implication: teams need a discovery model that does not depend on onboarding events or directory records alone.
How network traffic reveals agent behaviour
The article's core technical point is that AI agents must communicate with their model and with downstream systems to operate. That creates a behavioural footprint in network traffic, including east-west calls, tool invocation patterns, and model communication paths. By observing those flows continuously, an organisation can infer that an agent exists even when no identity record does. This is fundamentally different from SaaS administration or IdP logging, because it detects execution reality instead of declared intent.
Practical implication: classify agent presence from runtime traffic patterns, not from whether a platform says an identity exists.
Why agent classification matters after discovery
Discovering an agent is not enough if every agent is treated the same. The article distinguishes user-facing copilots from autonomous agents that can spawn sub-agents, call APIs, retrieve secrets, and interact with internal systems. Those behaviours create different identity and privilege risks. A user AI agent may look like an interactive session, while an autonomous agent can generate broader east-west activity and expand its own execution footprint. Governance must therefore separate visibility from risk classification before access decisions are made.
Practical implication: maintain distinct handling for user AI agents and autonomous agents because their access patterns and blast radius differ materially.
Threat narrative
Attacker objective: The objective is to operate or abuse AI identities without visibility, ownership, or governance, so their access can expand unchecked across the environment.
- Entry occurs when an AI capability is enabled inside SaaS, through a personal credential, or through an agentic workflow that never creates a conventional identity record.
- Escalation happens when the agent gains runtime access to internal systems, APIs, secrets, or sub-agents without ever being fully captured in identity governance logs.
- Impact follows when unmanaged agents operate outside the security perimeter, widening the attack surface and obscuring accountability for access and data movement.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Shadow AI is a discovery failure, not just a governance gap. The article shows that agents can be created inside SaaS tools, by users, or by other agents without ever entering the identity stack. That means the programme did not simply miss a review cycle, it lacked a mechanism to observe the identity in the first place. The practitioner conclusion is that discovery must be treated as a control domain of its own, not a by-product of provisioning.
Provisioning records are no longer a reliable proxy for AI identity existence. Identity systems were designed to track entities that are intentionally registered before use. That assumption fails when an autonomous workflow or embedded SaaS capability can create agentic activity without a provisioning event. The implication is that governance models built on directory completeness no longer describe the real attack surface.
Runtime visibility is now the boundary between managed and unmanaged AI behaviour. Network-level observation becomes the deciding factor because the agent’s operational truth is expressed in communication patterns, not in admin consoles. That changes the discipline from account administration to behavioural accountability. Practitioners should treat runtime observability as a first-class identity governance control for agentic environments.
Agent classification must follow behaviour, not branding. A copilot, a user-facing assistant, and an autonomous agent can all sit inside the same SaaS ecosystem, but their governance exposure is not equivalent. The article’s distinction between session-oriented agents and sub-agent-spawning autonomous workflows reflects a deeper control problem: privilege analysis only works when you know which runtime pattern you are governing. The practitioner implication is to classify by observed execution model before applying policy.
From our research:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
- A useful next step is to compare discovery coverage with OWASP Agentic AI Top 10 so runtime visibility, tool misuse, and governance gaps are assessed together.
What this signals
Shadow AI discovery is becoming a baseline governance requirement. If agents can appear through SaaS enablement, personal credentials, or runtime delegation, identity programmes need a control that sees execution rather than just registration. That is why network-level observability is emerging as a practical companion to IAM and SaaS governance, especially when the environment includes both human sessions and machine-created identities.
With 80% of organisations already reporting AI agents acting beyond their intended scope, per AI Agents: The New Attack Surface report, the operating assumption has changed. Practitioners should expect the next governance failure to be a discovery failure first, then a privilege failure second.
A strong programme will now tie discovery to agent classification, ownership, and lifecycle controls. The organisations that can map behaviour back to a responsible owner will be able to contain agent sprawl faster than those waiting for ticket-driven inventory completeness.
For practitioners
- Build a runtime discovery path for AI identities Correlate network flows, model communication, and east-west activity so agents can be detected even when no IdP object or provisioning event exists.
- Separate agent inventories from user identity inventories Track AI agents as their own governance class, with ownership, scope, and lifecycle records that do not depend on a human account session.
- Classify agents by observed behaviour Distinguish session-oriented copilots from autonomous workflows that can spawn sub-agents, call APIs, and retrieve secrets before assigning control requirements.
- Map every discovered agent to an accountable owner Record the human, team, or system responsible for each discovered agent so unmanaged runtime activity can be triaged and offboarded quickly.
- Review SaaS enablement paths for hidden agent creation Check where employees can activate AI capabilities without a ticket, IdP event, or security review, then close those blind spots in the platform approval process.
Key takeaways
- Shadow AI agents evade conventional IAM because they can be created without provisioning, tickets, or IdP events.
- Runtime traffic analysis is the practical way to detect agents that never enter the identity stack.
- Discovery, classification, and ownership now have to work together if organisations want to govern agentic sprawl.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A4 | Agent discovery and tool misuse risks are central to the article's runtime visibility gap. |
| NIST AI RMF | Agent accountability and governance align with AI risk management for autonomous behaviour. | |
| NIST CSF 2.0 | PR.AA-01 | Identity management and access governance are affected by undiscovered AI identities. |
Define governance ownership for AI agents and verify monitoring covers runtime behaviour, not just registration.
Key terms
- Shadow AI: Shadow AI is an AI capability or agent that operates in an environment without formal approval, inventory, or governance visibility. In practice, it may be created by users, embedded in SaaS tools, or spawned by other agents, which means security teams cannot rely on normal identity records to find it.
- Agent discovery: Agent discovery is the process of identifying AI agents and related runtime activity across an environment. Unlike traditional inventory management, it must infer presence from behaviour, communication patterns, and downstream system access when no provisioning event exists.
- Runtime observability: Runtime observability is the ability to see what an identity or workload actually does while it is operating. For AI agents, that means tracking model communication, tool calls, and east-west traffic so governance can be based on real behaviour rather than declared configuration.
- Agent classification: Agent classification is the practice of separating different AI runtime patterns into distinct governance groups, such as user-facing copilots and autonomous agents. This matters because the access, secrecy, and lifecycle controls required for each type are not the same.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
This post draws on content published by AuthMind: LLM Discovery Gap No One Is Talking About. Read the original.
Published by the NHIMG editorial team on 2026-06-22.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org