By NHI Mgmt Group Editorial TeamBased on Pomerium: “Shadow AI Is Already in Your Org. Here’s the 5-Minute Playbook to Secure It” (July 24, 2025)

TL;DR: Shadow AI is already widespread, with 55% of employees using GenAI without approval, 67 apps per enterprise on average, and 11% of pasted content containing confidential data, creating exposure across code, customer information, and road-map material, according to Pomerium. Identity-aware, zero-trust enforcement is now the baseline for governable AI usage, not an optional control layer.


At a glance

What this is: Pomerium argues that shadow AI is already embedded in day-to-day enterprise workflows and that identity-aware zero trust controls are necessary to make AI use governable.

Why it matters: For IAM, IGA, PAM, and security teams, the issue is not only data leakage but also whether policy can be enforced at the request level across human users, services, and AI agents.

By the numbers:

  • 55 percent of employees now use GenAI without approval.
  • 11 percent of all pasted content is confidential data.
  • 67 GenAI apps per enterprise are used on average.
  • 30 percent of AI-adopting enterprises have already experienced GenAI-related security incidents, according to Gartner research cited by Pomerium.

Context

Shadow AI is the use of generative AI tools, browser plug-ins, internal agents, or SaaS services without formal approval or governance. In practice, that means sensitive prompts, files, and code can move outside the controls that identity and data teams normally rely on.

Pomerium's central claim is that text-only safety filters are not enough because they do not know who initiated the request, which device was used, or which policy should have applied. For identity programmes, this shifts the problem from content moderation to request-level access control.

The article also treats shadow AI as a visibility problem, not just a blocking problem. If organisations cannot inventory the tools, users, and data paths involved, they cannot prove compliance or distinguish approved AI usage from unmanaged behaviour.


Key questions

Q: How should security teams govern shadow AI without blocking productivity?

A: Use visibility-based controls instead of blanket bans. Identify which tools are in use, who is using them, and what data they can access, then apply targeted policies by role and data sensitivity. That approach preserves legitimate AI adoption while reducing exposure from unsanctioned tools and unreviewed data paths.

Q: Why do text-only AI safety tools fail in enterprise environments?

A: They see content but not the identity context behind the request, so they cannot determine who acted, from where, or under which policy. That makes them too late to prevent leakage and too weak to support audit or enforcement.

Q: What breaks when AI agents rely on long-lived API keys?

A: Long-lived keys turn a single leaked secret into persistent authority, and agents create more places for that secret to leak through prompts, logs, cache layers, and tool outputs. Once the key is reused across tasks, revocation becomes slow and unreliable. Short-lived credentials are safer because they reduce the window in which exposure can be exploited.

Q: What is the difference between content filtering and identity-aware zero trust for AI?

A: Content filtering judges the prompt after it is already in motion, while identity-aware zero trust evaluates the requester, device, policy, and destination before access is granted. The latter can enforce least privilege and produce an auditable decision trail.


Technical breakdown

Why prompt filtering fails without identity context

Prompt filters inspect text after it has already left the environment, which makes them too late to control most shadow AI risk. They also miss the identity side of the transaction, including who sent the request, from which device, and under what policy context. That is why a blocked prompt often just pushes the user to another model, browser tab, or personal account. The control failure is not only in detection, but in the absence of an enforceable decision point tied to identity and request path.

Practical implication: enforce AI access at the request layer, not just at the content layer.

How identity-aware gateways change AI access control

An identity-aware gateway sits between the user and the AI endpoint, so policy can be evaluated before data leaves the organisation. In this model, identity, device, data class, and destination are part of the decision, not separate after-the-fact logs. That is materially different from firewall blocking or regex scanning because it gives the organisation a place to apply least privilege to AI workflows. The same pattern also works for services and agents, which matters when non-human identities initiate or relay AI requests.

Practical implication: treat AI traffic like any other privileged access path and put policy enforcement in front of the model endpoint.

Why short-lived credentials matter for AI workflows

AI scripts, plug-ins, and internal agents often rely on long-lived API keys or inherited access that is difficult to audit. Short-lived credentials reduce the window in which a leaked token can be reused and make access decisions more traceable. They also force access to be re-evaluated per request instead of remaining available across an entire session or workflow. In identity terms, this is less about convenience and more about ensuring that AI access is continuously scoped to the task, the actor, and the data involved.

Practical implication: replace persistent AI secrets with request-scoped credentials wherever possible.


Threat narrative

Attacker objective: The objective is to obtain sensitive enterprise data through unmanaged AI workflows and turn ordinary employee usage into a data-exfiltration channel.

  1. Entry occurs when employees use unsanctioned GenAI tools, browser plug-ins, or internal agents outside IT visibility, often by pasting sensitive material into public services.
  2. Credential or data exposure follows when those tools receive confidential code, customer information, or road-map documents that should never have left governed systems.
  3. Impact appears as data leakage, audit findings, and loss of intellectual property, with the added risk that banned use shifts to personal laptops, mobile hotspots, or burner accounts.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Shadow AI is a governance failure before it is a data-leak problem. The core issue is that organisations are allowing AI interactions to happen outside the identity, policy, and logging plane that governs everything else. Once the request happens beyond that plane, content filters become a compensating control rather than a control surface. Practitioners should treat unmanaged AI use as an identity governance gap, not a niche security exception.

Identity-aware zero trust is the only control model that matches how shadow AI behaves. Prompt redaction alone cannot answer who acted, what data was involved, or whether the request should have been allowed in the first place. That is why the enforcement point must move to identity, device, and data context at request time. For IAM and PAM teams, the practical conclusion is that AI access needs the same policy discipline as any other privileged pathway.

Identity-opaque AI access is the named gap shadow AI exploits. The article shows that teams cannot govern what they cannot see, and they cannot review what they did not log at the decision point. That makes access visibility and decision logging the minimum viable baseline for AI governance. The practitioner implication is that auditability must be designed into the access path, not reconstructed after the fact.

Shadow AI collapses the old boundary between human and non-human access governance. The article places humans, services, and agents in the same traffic control plane, which means the same programme now has to govern user behaviour, service credentials, and AI-mediated request paths together. That raises the value of identity-aware policy engines that can distinguish actor, context, and destination without relying on static network trust. The practical result is a unified access model rather than separate controls for people and machines.

Short-lived AI access is becoming a governance requirement, not an optimisation. Long-lived keys and broad entitlements are incompatible with AI workflows that can move quickly and unpredictably across tools. Once access is issued for convenience, the organisation inherits invisible persistence in scripts, plug-ins, and ad hoc automation. Practitioners should assume the next AI exposure will come from durable access, not sophisticated malware.

From our research library:

What this signals

Identity-aware access for AI is becoming the real control plane. Security teams should expect shadow AI to keep expanding through browser plug-ins, internal agents, and unsanctioned SaaS unless access is governed at the request level. The practical shift is from trying to classify every prompt to deciding whether the actor, device, and destination should be trusted at all.

Shadow AI changes the scope of identity governance. IAM and IGA teams can no longer treat AI usage as a separate innovation problem sitting outside the core access model. They need one governance view that covers human users, service identities, and AI-mediated sessions, or they will keep rediscovering the same exposure through different tools.


For practitioners

  • Define approved AI access paths List the GenAI tools, plug-ins, internal agents, and SaaS endpoints that are allowed to receive enterprise data, then block everything else by policy.
  • Enforce identity-aware request controls Apply policy using user identity, device posture, data classification, and destination so the decision happens before prompts or files leave the environment.
  • Replace long-lived AI credentials Issue short-lived credentials for AI workflows and remove persistent API keys from scripts, agents, and browser-based automations.
  • Route AI logs into the SIEM Capture user, role, policy decision, request context, and destination for every AI interaction so security and audit teams can reconstruct usage.

Key takeaways

  • Shadow AI is not just a content problem. It is an identity and governance problem because unmanaged AI requests bypass the policy plane that normally protects enterprise data.
  • The article points to a control gap that starts with visibility and ends with auditability, which means blocking prompts after the fact is not enough.
  • The practical answer is request-level zero trust for AI workflows, backed by identity context, short-lived credentials, and logs that security and audit teams can trust.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-10 — Human Use of NHIShadow AI often routes sensitive data through people using unmanaged AI services and plug-ins.
NHI-02 — Secret LeakageThe article warns that prompts, code, and credentials can leave the organisation through unmanaged AI tools.
NHI-07 — Long-Lived SecretsThe article explicitly says long-lived API keys in agents or scripts are a breach waiting to happen.
Recommendation — Restrict human use of AI-enabled non-human identities to approved tools and enforce policy at request time. Prevent secret leakage into AI workflows by blocking sensitive data at the request boundary and logging all decisions. Replace long-lived secrets in AI workflows with short-lived credentials and revoke persistent tokens quickly.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe core problem is whether AI requests are authorised based on identity and context.
Recommendation — Apply PR.AA-05 to evaluate AI access using identity, entitlement, and request context before release.
NIST Zero Trust (SP 800-207)Policy enforcement point — Policy enforcement pointThe article's model depends on enforcing policy before data exits the organisation.
Recommendation — Place a policy enforcement point in front of AI endpoints so access is decided before prompts leave.
MITRE ATT&CKTA0006 — Credential AccessShadow AI can expose credentials and other secrets through pasted data and unmanaged workflows.
Recommendation — Map AI-enabled secret exposure to TA0006 and hunt for credentials leaving governed systems.

Key terms

  • 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-Aware Access: Identity-aware access is an authorization model that evaluates who or what is making a request, what it is trying to reach, and under what context. It replaces broad, persistent trust with request-level decisions. In agentic environments, it is the control that can contain a deceived agent before it reaches enterprise systems.
  • Short-Lived Attested Credential: A short-lived attested credential is a token or certificate issued for a specific run or workload after the platform verifies who or what is asking. It reduces replay risk because the credential is only useful within a narrow window and is tied to claims that can be checked at runtime.
  • Request-level policy enforcement: A control pattern that evaluates each access request at the moment it is made, using identity, context, and policy before allowing execution. For agentic and NHI workflows, this is the practical boundary that prevents token possession from becoming unchecked tool access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine 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 IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org