AI agent visibility gaps leave enterprise governance blind to shadow risk

At a glance

What this is: This is an analysis of why API-based AI agent inventory leaves major visibility gaps, with the key finding that configured agents are not the same as active agents.

Why it matters: It matters because IAM, IGA, and security teams cannot govern what they cannot see, and incomplete discovery breaks entitlement mapping, ownership, and runtime control for AI agents and adjacent non-human identities.

By the numbers:

• Across Obsidian's customer base, agent counts grew from under 500 in late 2024 to nearly 95,000 by February 2026.
• 38% of agents carried medium, high, or critical risk factors from the moment they deployed.

👉 Read Obsidian Security's analysis of AI agent visibility gaps and shadow risk

Context

AI agent visibility is now an identity governance problem, not just a tooling problem. When discovery depends on APIs alone, teams only see what was formally provisioned, not what is actually running. That leaves shadow AI, built-in SaaS AI features, and personal-account activity outside the control plane.

For IAM and IGA teams, the issue is that runtime behaviour, ownership, and entitlement scope no longer align cleanly with configuration records. In practice, that means the programme may have a clean inventory and still miss the agents most likely to move data, reach production systems, or bypass documented governance paths.

Key questions

Q: How should security teams discover AI agents that are not in IAM inventories?

A: Use multiple discovery paths at once: declared agent registries, repository scanning, plugin and app store monitoring, network analysis, and identity analytics. The goal is not just to find traffic, but to correlate activity back to an owner, lifecycle state, and delegated identity so shadow AI can be governed instead of merely observed.

Q: Why do AI agents create a bigger governance problem than ordinary endpoint tools?

A: Because an AI agent can execute many file reads, API calls, and transfers in one session without a human approving each step. That collapses the assumption that access is reviewed before action. Governance must therefore focus on delegated machine activity, not only on user approval flows.

Q: What do security teams get wrong about AI governance inventories?

A: They often inventory only the AI they built themselves and miss embedded AI inside vendor platforms and other shadow AI. That creates a false sense of control because the real decision surface is broader than the visible project list. A useful inventory must cover models, use cases, agents, owners, and the approvals attached to each one.

Q: How should organisations govern AI agent risk once discovery is in place?

A: Treat discovery as the first control, then attach ownership, access scope, behavioural monitoring, and review cadences to each active agent. Governance should be based on who can act, what they can reach, and whether the action still matches the business purpose. That is the point where policy becomes enforceable.

Technical breakdown

Why API-based inventory misses active AI agent behaviour

API inventories only expose agents that were created through sanctioned channels and registered in the systems being queried. They do not reveal activity that occurs inside SaaS features, personal accounts, or low-code platforms that never emit a new integration event. That means the inventory reflects administrative intent, not live operational state. For identity teams, the technical trap is assuming that a list of configured agents is equivalent to an authoritative asset register. It is not. The result is incomplete discovery, incomplete owner mapping, and incomplete control coverage.

Practical implication: treat API inventory as a source, not the source of truth, and pair it with runtime discovery that can see actual agent execution.

How shadow AI appears inside trusted SaaS platforms

Shadow AI does not always arrive as a new app or external integration. It can surface as built-in capabilities inside already trusted platforms such as collaboration, CRM, and productivity tools. Because these features activate within existing SaaS sessions, they may not create a new OAuth grant or a fresh connection record. That makes them structurally invisible to controls designed around app onboarding. The governance issue is not that the platform is unknown, but that the AI behaviour is embedded in a trusted channel that security teams rarely inspect at the same granularity as external integrations.

Practical implication: extend review and monitoring to AI features already embedded in sanctioned SaaS applications, not just third-party agent connections.

Why agent behaviour matters more than agent configuration

The article shows a sharp gap between what agents are configured to do and what they actually do once live. In identity terms, this is the difference between declared access and observed access. Once an agent can download large volumes of data or connect to production systems, the risk profile depends on runtime behaviour, not on the provisioning record. That is especially important for service accounts and tokens backing AI agents, because they often inherit broad access without the governance signals usually attached to human identity. Behavioural monitoring becomes necessary because configuration alone cannot explain blast radius.

Practical implication: add behavioural controls and usage analytics to catch agent actions that exceed their declared scope.

Threat narrative

Attacker objective: The objective is to operate high-access AI agents outside governance coverage so they can move data or reach production systems without detection.

1. Entry occurs when AI agents are created through sanctioned APIs, SaaS features, personal accounts, or low-code tools that bypass standard inventory paths.
2. Escalation happens when those agents authenticate with OAuth tokens or service accounts that are outside the IdP's normal evaluation flow and therefore escape human-style governance checks.
3. Impact appears when invisible agents gain live connectors to production systems, move large volumes of data, and expand the blast radius beyond the visible inventory.

Breaches seen in the wild

• McDonald's McHire AI Chatbot Default Credentials — Default credentials in McDonald's McHire AI recruitment chatbot expose 64 million job application records.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API inventory is not identity governance for AI agents. API-driven discovery can identify configured agents, but it cannot prove what is active, embedded, or operating through trusted SaaS features. That means the control problem is not just a missing tool, but a broken assumption that administrative records represent runtime identity. The implication is that governance for AI agents must begin with behavioural truth, not configuration completeness.

Shadow AI is now a lifecycle problem as much as a discovery problem. The article shows agents created by accounts that no longer exist, agents with no documented owner, and agents living inside platforms already approved by the business. That combination breaks ordinary joiner-mover-leaver assumptions because the identity may persist after the creator is gone. Practitioners should read this as evidence that offboarding, ownership, and review are not aligned to the real lifecycle of AI agents.

Identity blast radius is the right concept for agent governance. A single AI agent can move far more data than surrounding users and applications, which means governance should be measured by reachable systems and reachable data, not by headcount. That is why the named concept matters: the larger the invisible agent footprint, the larger the unmanaged blast radius. Security leaders need to treat agent discovery as a prerequisite for any meaningful policy, enforcement, or risk scoring.

Built-in SaaS AI features collapse the boundary between application governance and identity governance. When Copilot, Einstein, Rovo, or similar features activate inside trusted software, security teams inherit identity risk without a clean integration event. That means app owners, IAM teams, and cloud security teams all need the same operational picture. The field should expect more governance failure from hidden capability than from obvious rogue deployments, and the control model must adapt accordingly.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, 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.
• OWASP NHI Top 10 is the next place to look if you need a control model for agentic behaviour, tool use, and identity abuse.

What this signals

Identity teams should expect agent discovery to move from a point-in-time exercise to a continuous control. As AI features spread inside approved SaaS platforms, the useful unit of governance becomes observed behaviour across sessions, not registered integrations. That is where browser-level and runtime visibility will increasingly sit beside IAM and IGA rather than beneath them.

Identity blast radius: the practical measure of AI agent risk is how far an agent can move data or reach systems before governance sees it. Once that concept becomes operational, teams can stop asking only how many agents exist and start asking how much damage each invisible agent can do. The programme implication is a shift from inventory completeness to reachability control.

For practitioners

• Correlate API discovery with runtime visibility Use API inventory for baseline coverage, then add browser or session-level telemetry to identify agents that appear only after they start acting inside SaaS tools and personal accounts.
• Review embedded AI features in approved SaaS apps Inventory AI capabilities already turned on inside collaboration, CRM, and productivity platforms, because those features can create identity risk without a new OAuth grant or connection event.
• Map ownership to live agent activity Require a named business and technical owner for every active agent, then reconcile that ownership against observed usage, connector scope, and data access patterns.
• Separate configured agents from active agents Build reporting that distinguishes agents present in administrative records from agents observed in execution, especially where service accounts and tokens back the workload.

Key takeaways

• API-based inventories cannot be treated as authoritative for AI agents because they miss active behaviour inside trusted SaaS and non-sanctioned channels.
• The governance gap is already visible in scale, with agent populations rising rapidly and a large share of deployments showing medium to critical risk from day one.
• Practitioners need runtime discovery, ownership mapping, and behavioural monitoring before policy, because control built on incomplete inventory will always be incomplete.

Key terms

• AI agent inventory: An AI agent inventory is a complete record of autonomous or semi-autonomous software entities, including their permissions, tools, and reachable resources. It is a governance baseline because teams cannot review, restrict, or remediate agent access until they know exactly what the agent estate contains.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Runtime Visibility: The ability to observe what an AI client actually accessed, which tools it used, and how it behaved during a session. It is more useful than entitlement snapshots for agent governance because it captures executed reality, not just approved access.

What's in the full article

Obsidian Security's full blog post covers the operational detail this post intentionally leaves for the source:

• How browser-level visibility identifies AI activity inside SaaS sessions that API inventories do not surface
• What kinds of embedded AI features in tools like collaboration and productivity platforms create hidden identity risk
• How Obsidian distinguishes configured agents from active agents in customer environments
• Why the company argues that incomplete inventory undermines entitlement mapping, runtime enforcement, and risk scoring

👉 The full Obsidian Security post covers browser visibility, shadow AI channels, and the inventory gaps behind hidden agent activity.

Deepen your knowledge

NHI Governance, agentic AI identity, machine identity security, and identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.