Blog

Jul 23, 2026 | 10 min

How to Detect Shadow AI Across Cloud, SaaS, and Agents

Token Security Staff

No items found.

Key Takeaways

To detect shadow AI, correlate AI app use, custom GPTs, OAuth grants, endpoint agents, and sensitive data movement.
Unsanctioned AI is already the norm inside most enterprises, with ISACA's 2026 AI Pulse Poll finding 90% of digital trust professionals say employees use AI tools while only 38% of organizations have a comprehensive AI policy, which is why detecting shadow AI is an identity problem before a model problem.
Shadow AI detection needs identity context because an unsanctioned tool often persists through tokens and SaaS connectors.
Identity is what turns a discovery list into a control: name the agent, map what it can reach, and decide at execution time.

How do you detect shadow AI?

Detect shadow AI by combining identity, network, SaaS, browser, endpoint, and data activity into one inventory of AI tools, agents, custom GPTs, OAuth apps, and unmanaged API calls. Surveys miss what employees and developers connect on their own. Shadow AI detection works when every discovered agent is mapped to an owner, credential, data class, and business purpose.

Start with IdP, network, browser, SaaS, and data activity rather than employee surveys.
Look for custom GPTs, agents, browser extensions, OAuth grants, and unmanaged API traffic.
Map each discovered tool to an owner, identity, data class, and business purpose.
Decide whether the tool should be approved, restricted, reviewed, or blocked.

Quick Facts

Risk	What it means	How to address it
Public GenAI use	Employees use tools outside approved controls.	Correlate SSO, network, browser, and data events.
Hidden custom GPTs	Agents run under personal or team accounts.	Inventory custom GPTs and owners.
OAuth persistence	Revoking web sessions does not remove app tokens.	Review grants, scopes, and refresh tokens.
Data upload paths	Sensitive files move into unmanaged tools.	Match prompts and connectors to data classification.

What telemetry exposes shadow AI fastest?

Shadow AI rarely appears first as an approved application. It shows up as identity and traffic evidence: a new OAuth grant, a browser extension calling an AI service, an API key stored in a developer workspace, or repeated data uploads from a SaaS connector. Detection should join these signals instead of treating them as separate alerts.

IdP and SSO logs show new AI apps, consent grants, and unusual login paths.
Network and proxy logs show unmanaged AI domains and high-volume uploads.
SaaS audit logs show connected apps reading customer, employee, or code data.
Repository and secret scans show keys used to connect unsanctioned agents.

The goal of shadow AI detection is not to shame teams for experimentation. It is to identify which tool is acting, what identity it uses, what data it touches, and whether that use can be governed or must be blocked.

Shadow AI also needs a triage model. Not every discovery is an emergency, and treating every new AI domain as a critical alert burns analyst time. Rank findings by identity type, credential strength, data sensitivity, and whether the tool can write back to business systems. A browser visit to a public chatbot is different from an OAuth app with mailbox access or a custom agent connected to source code. The triage model tells security what to investigate first and gives employees a clear path to bring useful tools under governance.

Why is shadow AI detection different from SaaS discovery?

SaaS discovery shows which apps exist. Shadow AI detection must also show which agents, custom GPTs, browser extensions, OAuth grants, prompts, and data paths are active. A revenue team connects a public GenAI assistant to Google Drive, installs an OAuth app in Salesforce, and shares prompts with customer details. None of that passes through a procurement queue, and the data has moved before security ever sees the app. The NIST AI Risk Management Framework sorts AI risk into Govern, Map, Measure, and Manage. Map is the function shadow AI defeats first, because nothing can be measured or managed while the agent, its credential, and its owner are all still unknown.

The pattern shows up in survey data before it shows up in incident reports. Gartner found that 69% of surveyed cybersecurity leaders suspected or had evidence of prohibited public GenAI use, and projected that 40% of enterprises will face shadow AI-linked incidents by 2030. MITRE ATLAS catalogues how adversaries attack AI-enabled systems. The OWASP LLM Top 10 covers the model layer, including sensitive information disclosure. The OWASP NHI Top 10 covers the machine layer, where unfinished offboarding and leaked secrets keep unsanctioned tools alive long after anyone stopped using them.

Why SaaS discovery keeps missing shadow AI

The directory is not wrong. It is answering a different question. It reports what was provisioned, which is exactly what a SaaS review asks it for. Shadow AI arrives by consent instead: a browser agent authorized against someone's own session, an OAuth token granted in three clicks, a custom GPT reading documents nobody classified. None of that touches the provisioning path, so IAM has nothing to report, the SIEM logs calls whose origin it cannot name, and the admin console lists only what somebody installed on purpose. A clean review and an unmonitored agent are entirely compatible findings.

The operating model has to be complete before it can be strict. Find every AI agent, service account, OAuth app, access token, and workload identity, including the ones issued through user consent rather than provisioning. Establish what each can reach, what it does in practice, and how far the damage extends if it is misused. Then put the decision ahead of the action, so a request can be denied, approved, narrowed, or sent to a human.

Shadow AI Discovery Signals

Stage or path	What to verify	Failure signal	Owner or action
IdP and SSO logs	New app sign-ins or bypassed SSO	AI tool used outside approved app catalog	SaaS security
OAuth grants	Scopes requested by AI apps and extensions	Read or write scopes on sensitive SaaS data	IAM team
Network telemetry	Traffic to public GenAI and agent endpoints	Uploads from restricted segments	Security operations
Browser and endpoint data	Extensions, local agents, and desktop clients	Agent installed without approval	Endpoint team
Data activity	Sensitive files copied into prompts or connectors	Customer data in unmanaged AI path	Data security

What signals help security teams detect shadow AI?

Detection starts from a record of what should exist, because that is what makes everything else stand out. The record carries the owner, purpose, identity provider entry, tool list, data classes, credential type, maximum privilege, and retirement date. Compare it against live telemetry and the gaps become findings: an agent calling a tool nobody registered, reaching a data class it was never cleared for, or assuming a role beyond its boundary. Each of those should fail or move to review.

A finding is only actionable if it names what triggered it: no owner on record, scope wider than the task, a data class outside the boundary, a token past its age limit, behavior that has drifted from baseline, or an approval path that leads nowhere. Without that, teams inherit a list of unknown agents and no way to triage it. With it, every row points at one fixable condition. The same reasoning covers AWS IAM, Azure Entra ID, Google Cloud IAM, Kubernetes service accounts, and SaaS OAuth grants.

Common Pitfalls to Avoid

Relying on surveys and approved app lists instead of telemetry from real AI usage.
Counting an agent as known because it appeared once in a discovery scan, without tracking what it did next.
Treating a sanctioned tool as permanently safe while its connectors, scopes, and data reach keep expanding.
Building a shadow AI inventory that lives apart from the NHI program, so the same identity gets found twice and owned by nobody.

How does Token Security approach shadow AI detection?

The challenge

Ask where the AI is actually running and the honest answer is five places at once. Cloud, SaaS, CI/CD, browser sessions, and AI platforms each hold part of the picture, and none was designed to hand its part to the others. IAM and PAM were built for an actor that logs in and can be asked about it afterward. A custom GPT authorized inside a browser tab does neither, which is how it survives a review that was looking in the right place with the wrong instrument.

The approach

Token Security makes the discovered agent a non-human identity, and everything else hangs off that. Discovery surfaces it along with whatever credentials it is carrying. Entitlement mapping and blast-radius analysis establish reach and consequence. Behavioral baselines separate ordinary use from drift, automated remediation narrows what the agent holds, and lifecycle governance decides how long it holds it. Owner, permissions, behavior, and credentials all resolve to one record, which is what turns discover, understand, enforce from a slogan into a sequence.

The outcome

The practical effect is that discovery stops being a dead end. An agent found on Monday is governed by Friday, under the controls already covering service accounts, machine identities, OAuth apps, and the rest of the machine estate. Token Security keeps non-human identity, service account exposure, OWASP NHI Top 10 risk, blast radius, and machine-first enforcement in one view, so a new find joins the existing program instead of starting a parallel one.

What security teams find when they go looking

Shadow AI detection fails when the security team only knows about the identities it approved. What makes a finding useful is naming the agent, tying it to real access, and handing the owner something narrow enough to act on.

"Token Security gives us visibility we simply didn't have before. We can now automatically identify and control custom GPT agents running in our environment and ensure the required security level. Knowing that no AI agent is operating beyond our oversight means we can confidently accelerate our AI adoption." — Tamir Ronen, Global CISO at HiBob

That is the test for any discovery claim: it has to end at a specific machine identity, a specific entitlement, and a specific fix.

Ownership decides what happens next. Once an agent holds access, the open questions are who answers for it, how far it reaches, and how fast the excess can come off.

"Non-human identity is a top priority for many teams and it is challenging to gain insight into the full scale and scope of the issue. Token provides an easy solution to get that visibility to then determine where you need to take action." — Mandy Andress, CISO at Elastic

Monitoring reports what an agent did. Governance decides what it may do next, and it works because accountability stays attached to the non-human identity taking the action.

Why visibility is no longer enough for AI governance

What improves from here is the quality of the evidence: which machine is acting, on what authority, how far it can reach, and whether the action should be allowed to finish. Agents leave very little time between a request and its consequences. Non-human identity governance is what gives a team somewhere to intervene inside that window. Once identity carries the decision, discovery stops producing lists nobody can act on and starts producing findings with an owner attached, which is the point at which agentic AI becomes something a team can run rather than merely observe.

FAQs

What does it mean to detect shadow AI?

To detect shadow AI means finding AI tools, custom GPTs, agents, extensions, and OAuth-connected apps that entered the environment outside formal approval. Detection requires IdP logs, SaaS grants, browser telemetry, endpoint data, network traffic, and data activity. A tool is not fully discovered until it has an owner, identity, data class, and permission scope.

How to find shadow AI in SaaS and cloud?

To find shadow AI, compare approved AI tools against actual usage in SSO, OAuth grants, SaaS audit logs, browser extensions, endpoint agents, and public GenAI traffic. Then inspect data access. A custom GPT with read scope on shared drive folders deserves higher priority than a tool used only with public data.

What is the difference between detect shadow AI and normal IAM?

The two disciplines start from opposite ends. IAM begins with a directory of users, groups, roles, and applications that someone deliberately provisioned, then works outward. Shadow AI detection begins with telemetry showing that something happened, then works backward until it reaches an owner. Agents, custom GPTs, browser extensions, and OAuth grants that arrived through a user's own consent are invisible from the directory end and obvious from the telemetry end.

Why does finding shadow AI matter?

Finding shadow AI matters because an unsanctioned tool does not stay a private productivity choice. It becomes a standing data path, held open by a token or connector that nobody reviews. Until the tool is discovered and tied to an owner, no one can say what it reached or whether it still has access.