Shadow AI agents expose the limits of inventory-first governance

At a glance

What this is: This analysis explains why shadow AI agents emerge faster than enterprise registration and why identity-based governance is the control that changes the problem.

Why it matters: It matters because IAM, NHI, and security teams need to govern unregistered agents through identity, not through one-time discovery exercises that age out immediately.

By the numbers:

• Only 37% had policies to manage AI or detect shadow AI at all

👉 Read Scramble ID's analysis of how to find shadow AI agents

Context

Shadow AI agents are AI tools, copilots, or automated workflows that act on enterprise data or systems without being registered, owned, and governed. That creates an identity problem before it becomes an AI problem, because the estate includes actors that can hold credentials, call APIs, and trigger business workflows with no accountable owner.

The governance gap is not just discovery. Enterprise usage keeps moving into personal tools, SaaS-embedded agents, and unattended service credentials, which means security teams need to treat every agent as an identity subject. For IAM and NHI programmes, the question is no longer whether agents exist, but whether they can prove who they are before they act.

Key questions

Q: How should security teams find shadow AI agents in enterprise environments?

A: Start with identity surfaces, not model telemetry. Review OAuth consent grants, SaaS admin consoles, egress to model and MCP endpoints, procurement records, and service-account inventories. The goal is to identify agents that can act on enterprise data without a named owner, a revocation path, or a registered identity subject.

Q: Why do shadow AI agents create more risk than classic shadow IT?

A: Classic shadow IT usually increases data exposure. Shadow AI agents can hold credentials, call APIs, and change records on their own, which expands the blast radius from passive use to active execution. That makes identity, privilege scope, and revocation the decisive controls, not just application blocking.

Q: What do organisations get wrong about governing AI agents?

A: They often treat agents as tools to catalogue instead of identities to govern. That leaves consent grants, inherited secrets, and SaaS-embedded automation outside lifecycle review. Effective governance starts when every sanctioned agent has ownership, authority limits, and a way to fail authentication if it is unregistered.

Q: Who should be accountable when an unregistered AI agent causes a security incident?

A: Accountability should sit with the business and technical owners of the identity pathway that allowed the agent to act. If the issue came through consent, credential sprawl, or SaaS enablement, the accountable team is the one responsible for access lifecycle, not the team that discovered the agent after the fact.

Technical breakdown

Why shadow AI agents evade traditional inventory models

Traditional inventories assume assets are registered before they do useful work. Shadow AI agents break that assumption because adoption happens first, often through OAuth consent grants, SaaS admin toggles, or corporate credit card subscriptions. Once an agent can access mail, files, calendars, or data connectors, it behaves like a live identity even if no security team has documented it. The operational issue is not just missing documentation. It is missing authority boundaries, because the agent can keep operating while the programme still thinks it is evaluating a tool rather than governing an identity.

Practical implication: search for agent activity in consent logs, SaaS admin consoles, and expense records instead of waiting for a complete asset inventory.

How compromised NHIs become the fuel for shadow agent abuse

Shadow agents rarely need novel exploitation when they inherit or encounter long-lived credentials. API keys in code, stale service accounts, and tokens stored outside managed vaults give an agent the ability to act with the permissions already attached to those identities. That turns NHI sprawl into an execution layer for unsanctioned AI behaviour. The identity risk is not simply secret leakage. It is that a bearer credential lets an unregistered actor appear legitimate enough to call systems, modify records, and chain actions without a durable owner of record.

Practical implication: tie every agent-facing secret to a named system, a named owner, and a revocation path before the credential is allowed to persist.

Why per-agent identity and signed actions change the control model

The durable control is not better discovery, but stronger identity proof. When each sanctioned agent carries its own identity and signs every call, it becomes possible to distinguish approved automation from rogue behaviour at the point of execution. This shifts security from snapshot-based hunting to exception handling, where anything unable to present valid identity is blocked by design. In practical terms, the control model moves from asking whether an agent is on the list to asking whether the call itself can be authenticated, authorised, and audited.

Practical implication: require per-agent identity, scoped authority, and cryptographic proof on actions so unregistered agents fail at the call boundary.

Threat narrative

Attacker objective: The objective is to use a legitimate-looking AI actor to access enterprise data and execute actions without security ownership or oversight.

1. Entry begins when a user grants OAuth consent, enables a SaaS copilot, or purchases an unmanaged AI tool that gains access to enterprise data.
2. Credential access follows when the agent inherits service-account secrets, refresh tokens, or API keys already present in the environment.
3. Impact occurs when the unregistered agent reads, modifies, or exfiltrates data and triggers workflows that the security programme never associated with a governed identity.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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 an identity governance problem before it is an AI governance problem. The decisive failure is not model quality or user enthusiasm, but the absence of a governed identity subject for the agent. Once a tool can act on enterprise data without registration, ownership, or revocation, IAM has already lost the first control point. The practitioner implication is clear: unmanaged agents must be treated as identity exceptions, not as software curiosities.

Identity inventory is too slow to be the primary defence against shadow agents. Inventory assumes a stable asset set, but agent adoption is dynamic and often invisible until credentials are used. That makes inventory useful for exposure reduction, but not sufficient for runtime control. The practitioner implication is to move governance closer to the call boundary, where the agent must prove identity before it can exercise authority.

OAuth consent sprawl and NHI secret sprawl are now the same governance surface. A user-granted token and a stale service account both create machine actors that can operate outside formal oversight. The shared failure mode is unowned delegated access. The practitioner implication is to unify review, revocation, and lifecycle controls across consent grants, service accounts, and AI agents instead of managing them as separate queues.

Per-agent identity is the named concept that changes the operating model. When every sanctioned agent has its own identity and signs every action, the question changes from discovery to authentication. That does not eliminate shadow AI, but it collapses the utility of unregistered actors because they have nothing to present at the policy boundary. The practitioner implication is to design for failed authentication, not just failed discovery.

Shadow AI exposes the weakness of policy-only AI oversight. Organisations do not fail because they lack AI policy language; they fail because policy without identity enforcement cannot stop an unsanctioned agent from acting. The result is a governance stack that can describe the risk but cannot bound it. The practitioner implication is to align policy, identity proof, and revocation into one control chain.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• For the lifecycle and control-model angle, see Ultimate Guide to NHIs for the broader NHI governance baseline.

What this signals

Per-agent identity is becoming the practical boundary between sanctioned automation and shadow AI. As more agents arrive through SaaS features, OAuth grants, and unmanaged subscriptions, security teams need a control that works at the call boundary rather than at quarterly review time. That is why identity proof, scoped authority, and revocation paths matter more than a larger inventory spreadsheet.

Shadow AI also collapses the separation between human misuse and machine misuse. A worker can introduce an unmanaged agent with a few clicks, but the resulting access behaves like a machine identity problem once credentials are issued. Teams that still separate human IAM from NHI governance will miss the point where the risk becomes actionable.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, the opportunity set for unsanctioned agents is already broad, according to the Ultimate Guide to NHIs. The programme response is to unify secrets governance, SaaS review, and agent registration into one control path.

For practitioners

• Map every agent-like actor to an owner and revocation path Review OAuth grants, SaaS copilots, workflow bots, and service accounts together, and require each one to have a named business owner, a technical owner, and a documented offboarding path.
• Sweep for unattributable secrets in the places agents actually use Search code repositories, CI variables, vault paths, and cloud IAM for long-lived credentials that cannot be tied to a sanctioned system and a human approver.
• Treat consent logs as an identity detection source Monitor identity-provider consent grants for broad scopes, unfamiliar owners, and grants that enable mail, file, calendar, or directory access without a security review.
• Require signed calls for sanctioned agents Bind approved agents to per-agent identity and cryptographic proof so any actor unable to sign its request is blocked at the policy boundary.
• Unify NHI and AI governance reviews Put service accounts, tokens, and AI agents into the same review and offboarding workflow so unsanctioned access is removed on the same cadence as other machine identities.

Key takeaways

• Shadow AI is a governed-identity problem, not just an unsanctioned-tool problem.
• The evidence shows the risk is already material, with breach cost and breach frequency both rising where shadow AI is present.
• Per-agent identity, signed actions, and unified lifecycle control are the mechanisms that turn discovery into enforceable governance.

Key terms

• Shadow AI Agent: An AI agent, copilot, or automation tool that acts on enterprise data or systems without being registered, owned, and governed. The defining issue is not whether the tool is intelligent, but whether it has accountable identity, lifecycle oversight, and enforceable access boundaries.
• Per-Agent Identity: A model in which each sanctioned AI agent receives its own identity for authentication, authorization, and audit. This lets security teams tie every action to a specific actor, rather than allowing shared credentials or generic automation accounts to blur accountability and hide misuse.
• Consent Grant Sprawl: The accumulation of OAuth permissions and delegated access across users, apps, and admin consoles without a clear ownership model. In practice it creates a shadow access layer, because tools can keep calling data sources long after the security team has lost sight of why access was granted.
• Identity Boundary: The control point where an actor must prove who it is before it can access a system or trigger an action. For AI agents, the boundary matters because discovery alone is too slow; the request itself must be authenticated, authorised, and auditable at execution time.

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 Scramble ID: Shadow AI Agents: How to Find the Agents Nobody Registered. Read the original.