AI threat prevention is now an NHI governance problem

At a glance

What this is: This checklist frames AI threat prevention as a visibility, access, and third-party governance problem across shadow AI, permissions, privacy, and AI-enabled attacks.

Why it matters: IAM and NHI teams need to treat unmanaged AI tools like privileged external actors because they can introduce persistent access paths and data exposure routes.

👉 Read the vendor checklist on AI threat prevention and shadow AI risk

Context

AI adoption is now creating a familiar identity problem in a new form: tools appear faster than governance can absorb them, and each one may request access that looks routine until it is combined with data retention, token persistence, or overbroad SaaS permissions. For IAM and NHI practitioners, the issue is not whether AI is useful. The issue is whether the organisation can see, classify, and govern every AI-linked identity before it becomes a standing risk.

The article’s checklist starts from a defensible premise. AI tools should be treated as part of the supply chain, because they process enterprise data and often operate through non-human credentials such as OAuth grants, API keys, and persistent tokens. That starting point is typical of mature security thinking, but many organisations still handle AI adoption as a local productivity choice rather than a governed identity domain.

Key questions

Q: How should security teams govern shadow AI in the enterprise?

A: Treat shadow AI as an identity and data-governance issue, not just an application-discovery problem. Every tool should be assigned an owner, mapped to its credentials and scopes, and reviewed for data retention and third-party handling. If a tool cannot be owned or revoked cleanly, it should not keep access to enterprise systems.

Q: Why do AI tools create NHI risk for IAM teams?

A: AI tools often authenticate through non-human credentials such as OAuth grants, API keys, and persistent tokens. Those credentials can outlive the initial business need and widen blast radius if compromised. IAM teams should therefore manage AI access with the same discipline used for service accounts and other NHIs.

Q: What is the difference between AI app approval and AI identity governance?

A: App approval asks whether a tool is useful and acceptable to deploy. AI identity governance asks who or what can authenticate, what scopes are granted, how long access lasts, and how it is revoked. The second control set is broader and more durable, which is why it matters more for risk reduction.

Q: Should organisations treat AI vendors like third-party suppliers?

A: Yes. If an AI service processes company data, it belongs in third-party risk review because retention, training reuse, subcontracting, and incident handling all affect exposure. Security, privacy, and IAM should evaluate the service together before access is granted.

Technical breakdown

Shadow AI discovery and identity inventory

Shadow AI is any unmanaged AI tool, embedded feature, or autonomous workflow that has entered the environment without a formal inventory record. The technical issue is not only discovery of the application but discovery of the identities it creates or consumes. These can include OAuth consents, service accounts, API keys, delegated access, and human-created tokens that outlive the original use case. Once those credentials exist, they often inherit the trust of the parent account. That makes AI discovery an identity inventory problem as much as a software inventory problem. A security team that cannot map AI tools to credentials cannot reason about blast radius, revocation, or ownership.

Practical implication: Build a complete inventory that maps every AI tool to the credentials, scopes, and data paths it can reach.

Why OAuth scopes and persistent tokens expand blast radius

Many AI tools rely on delegated access because they need to read mail, documents, chats, or tickets on behalf of users. The risk comes when that delegation is broad, persistent, and poorly monitored. OAuth scopes can grant access far beyond the immediate task, and persistent refresh tokens can keep that access alive long after the user forgets the tool exists. If an attacker compromises the tool, steals the token, or abuses a connected account, the result is often lateral movement across SaaS systems rather than a single isolated compromise. Least privilege is not enough if scopes remain broad and revocation is not operationally reliable.

Practical implication: Review every AI-related OAuth grant for scope minimisation, token lifetime, and reliable revocation.

Vendor data handling and AI-enhanced attack paths

AI vendors may retain prompts, outputs, telemetry, or training data depending on their terms and architecture. That matters because sensitive enterprise content can reappear outside intended boundaries, even when the original use case looked narrow. The second layer of risk is attacker behaviour. AI can accelerate phishing, credential stuffing, and impersonation by making social engineering more convincing and scalable. The combined effect is that defenders must govern both data exposure and behavioural abuse. In practice, that means security teams need controls for data minimisation, contractual review, and detection logic that does not depend on humans being the only source of suspicious activity.

Practical implication: Assess retention, training, and logging terms before approval, then tune detection for AI-assisted abuse patterns.

Threat narrative

Attacker objective: The attacker wants durable, delegated access to enterprise data and communication channels without triggering traditional perimeter controls.

1. Entry occurs when an employee adopts an unvetted AI tool that requests access to email, documents, or chat platforms through delegated credentials.
2. Escalation follows when the tool receives broad OAuth scopes or persistent tokens that can be reused outside the original workflow.
3. Impact occurs when an attacker abuses the same access to move laterally across SaaS systems, harvest data, or impersonate users at scale.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 now an NHI discovery problem, not just an application approval problem. Security teams are still too often looking for sanctioned software while missing the credentials and data paths that AI tools create behind the scenes. The operational unit of control is no longer the app alone. It is the combination of app, identity, scope, and retention boundary. Practitioners should inventory AI as a non-human identity population, not as a side category of software.

Persistent OAuth grants are the most common way AI convenience becomes access debt. Once a tool receives delegated access, the organisation inherits the burden of monitoring, revocation, and auditability. The longer that access persists, the harder it is to justify under least-privilege or zero-standing-privilege principles. The practical conclusion is simple: every AI grant should have an owner, a purpose, an expiry, and a review path.

AI threat prevention must account for both credential abuse and content abuse. The article correctly links AI adoption to phishing, impersonation, and credential stuffing, which means the threat model is no longer limited to compromise of the tool itself. AI can also improve the attacker’s ability to look legitimate. That raises the bar for detection, because behavioral anomalies may now come from both machines and humans using machine assistance. Practitioners should align NHI controls with social-engineering detection and token governance.

Data handling terms are now part of identity governance for AI systems. If a vendor can store prompts, retain outputs, or reuse content for training, the organisation has effectively extended its trust boundary beyond the original user request. That makes procurement, privacy review, and IAM part of the same control plane. The field should stop treating AI data policy as a legal appendix and start treating it as an access decision. Security teams should insist on explicit handling rules before approving AI access.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, and 38% have no or low visibility, according to The State of Non-Human Identity Security.
• From our research: Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%, according to The State of Non-Human Identity Security.
• The governance pattern in AI environments points in the same direction, which is why practitioners should also use OWASP NHI Top 10 to frame agent access and trust decisions before adoption scales.

What this signals

Ephemeral access only helps if the organisation can actually see every non-human identity using it. The largest operational gap is still inventory, because untracked AI tools and SaaS integrations can keep access long after the workflow ends. With 85% of organisations lacking full visibility into OAuth-connected vendors, the programme challenge is not policy wording. It is enforcement across a messy, fast-moving identity estate.

Access review for AI systems should be measured in scope drift, not just account count. A tool with one broad delegated grant can create more exposure than many narrow accounts, especially when refresh tokens persist. That means IAM teams need to review consent, lifetime, revocation, and data use together rather than as separate queues.

Identity blast radius is the right lens for shadow AI governance. Once AI tools start touching mail, chat, documents, and SaaS APIs, the consequence of compromise is defined by how far a token can travel. The reader should expect more demand for NHI inventory, consent review, and delegated-access controls across the next planning cycle.

For practitioners

• Inventory all shadow AI and embedded AI features Map every AI tool, browser extension, and embedded assistant to its owner, data access, authentication method, and business purpose. Prioritise tools that connect to email, chat, documents, or ticketing systems because those integrations create the widest identity exposure.
• Reduce OAuth scope before approving AI access Require least-privilege scopes for each AI integration, set short token lifetimes where possible, and document a revocation process that actually works in production. Review persistent tokens first because they most often outlive the original use case.
• Classify AI tools as supply-chain vendors Put AI services through the same security review used for third parties. Confirm data retention, training reuse, logging, subcontractors, and incident notification terms before granting access to enterprise content.
• Tune detections for AI-assisted abuse Add monitoring for abnormal consent grants, rapid token use, mass export behavior, and suspicious login patterns that may reflect AI-enabled phishing or credential stuffing. Coordinate IAM telemetry with email and SaaS security logs.

Key takeaways

• AI threat prevention now sits at the intersection of shadow IT discovery, OAuth governance, and NHI control.
• Persistent delegated access is the main reason AI convenience turns into enterprise exposure.
• Security teams should govern AI tools like third-party identities, with owners, expiries, and revocation paths.

Key terms

• Shadow AI: Shadow AI is any AI tool, assistant, or embedded feature that enters the environment without formal approval or inventory. From a security perspective, the issue is not just the app itself. It is the identity, data access, and retention model that come with it.
• Delegated Access: Delegated access is permission granted to one system or user to act on behalf of another, often through OAuth consent or similar authorization flows. In NHI governance, delegated access matters because broad or persistent grants can survive long after the original business need has ended.
• Identity Blast Radius: Identity blast radius is the amount of damage an attacker can cause after compromising a credential, token, or account. It depends on scope, duration, monitoring, and connected systems, which is why AI tools with wide SaaS access create disproportionate risk.
• Persistent Token: A persistent token is a credential that remains valid across sessions and can continue authorizing access until it is revoked or expires. These tokens are risky in AI and SaaS environments because they often outlive the original workflow and are hard to track consistently.

Deepen your knowledge

AI threat prevention and shadow AI governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for delegated access and unmanaged AI tools, it is worth exploring.

This post draws on content published by Wing: The CISO’s Checklist for AI Threat Prevention. Read the original.