What do security teams get wrong about Shadow AI?

Why Security Teams Misread Shadow AI Risk

shadow ai is often framed as an unsanctioned app problem, but the bigger issue is usually hidden access. A chatbot with no inventory entry can still be harmless compared with an untracked token, a stale API key, or a service account that quietly inherited broad rights. That is why identity-first discovery matters. NHI governance research from Astrix Security & CSA shows only 1.5 out of 10 organisations are highly confident in securing NHIs, which is a warning sign for any team trying to control AI use only through software approval. The same pattern appears in incidents like the DeepSeek breach, where exposed secrets and over-broad access created far more damage potential than the application label suggested.

Security teams also underestimate how quickly AI use can outrun review cycles. If the control model starts with “what tool was approved?” instead of “what identity, secret, and authority does it hold?”, the wrong risk gets prioritised. Current guidance suggests pairing application discovery with secret discovery, service account review, and workload identity mapping. In practice, many security teams encounter Shadow AI only after an API key is abused or an autonomous workflow has already chained permissions into something far beyond the original intent.

How Shadow AI Becomes an Identity Problem in Practice

In operational terms, Shadow AI usually becomes risky when an AI feature, plugin, agent, or workflow is able to act with credentials that were never designed for autonomous use. Static RBAC is a weak fit here because it assumes predictable human roles, while agent behaviour is goal-driven and can change from one task to the next. Best practice is evolving toward intent-based authorisation, where the decision is made at runtime based on what the agent is trying to do, the dataset it wants to touch, and the systems it intends to call. That lines up with broader risk management guidance in the NIST Cybersecurity Framework 2.0 and the governance focus of the NIST Cybersecurity Framework 2.0.

For security teams, the practical sequence is usually:

• Find the AI tool, but also enumerate its tokens, certificates, and service principals.
• Check whether the identity is a human proxy or a true workload identity.
• Replace long-lived secrets with JIT ephemeral credentials where possible.
• Constrain tool use with policy-as-code so access is evaluated at request time.
• Revoke and rotate credentials when tasks finish, not on a quarterly schedule.

This is where workload identity matters. Agents and AI workloads need cryptographic proof of what they are, not just a password-like secret copied into a config file. Standards such as SPIFFE and SPIRE are often discussed here, but there is no universal standard for every environment yet. The DeepSeek breach is a useful reminder that once secrets are embedded in workflows or training artefacts, the boundary between approved and shadow usage becomes much harder to see. These controls tend to break down when legacy automation shares credentials with AI workflows because the same secret then inherits both human and autonomous reach.

Where the Edge Cases Actually Live

Tighter control often increases friction, requiring organisations to balance faster experimentation against tighter guardrails. That tradeoff is especially visible when teams want to let employees use AI tools quickly while still enforcing Zero Standing Privilege and short-lived access. There is no universal standard for this yet, but current guidance suggests that unmanaged convenience is what turns informal AI use into a persistent identity sprawl problem. If the environment uses shared connectors, vendor plugins, or multi-agent pipelines, the risk is not just one prompt or one app, but a chain of delegated actions that can expand beyond the original user’s intent.

Edge cases also appear in outsourced and third-party contexts. OAuth apps, sandbox integrations, and temporary vendor access can all hide Shadow AI behaviour if monitoring only looks at sanctioned software names. The NIST lens is still useful here because it pushes teams to document access, monitor activity, and treat governance as a continuous function rather than a one-time approval. The Astrix Security & CSA findings on limited visibility into third-party OAuth apps are especially relevant because they show how easily identity blind spots persist even in mature programmes. In practice, the hardest cases are autonomous agents running inside shared service accounts, because the agent’s actions become indistinguishable from legitimate automation until something unusual happens.

Related resources from NHI Mgmt Group

• What do teams get wrong about AI security and access management?
• What do teams get wrong when building clarification loops for AI agents?
• How should security teams govern machine identity credentials in agentic AI environments?
• How should security teams manage permissions for AI agents?