Notifications
Clear all
Topic starter
22/06/2026 4:55 pm
TL;DR: Shadow AI agents are already tied to breach exposure, with one in five breached organisations reporting shadow AI involvement, average breach costs rising by $670,000, and only 37% having policies to manage or detect it, according to IBM and Ponemon. Inventory alone is brittle; identity, signed actions, and scoped authority are the durable controls.
NHIMG editorial — based on content published by Scramble ID: Shadow AI Agents: How to Find the Agents Nobody Registered
By the numbers:
- Only 37% had policies to manage AI or detect shadow AI at all
Questions worth separating out
Q: How should security teams find shadow AI agents in enterprise environments?
A: Start with identity surfaces, not model telemetry.
Q: Why do shadow AI agents create more risk than classic shadow IT?
A: Classic shadow IT usually increases data exposure.
Q: What do organisations get wrong about governing AI agents?
A: They often treat agents as tools to catalogue instead of identities to govern.
Practitioner guidance
- 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.
What's in the full article
Scramble ID's full report covers the operational detail this post intentionally leaves for the source:
- Step-by-step hunting queries for OAuth consent grants, SaaS admin consoles, and model egress patterns.
- The exact logic for separating sanctioned agents from shadow agents in identity provider logs.
- Examples of how per-agent identity and signed actions change the control model in practice.
- Reference material on discovery paths and the operational role of an agent registry.
👉 Read Scramble ID's analysis of how to find shadow AI agents →
Shadow AI agents: what IAM teams need to govern now?
Explore further
22/06/2026 5:05 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Shadow AI agents expose the limits of inventory-first governance
