Key Takeaways
- Shadow AI now includes standalone agents running on user devices and unregistered model endpoints in cloud accounts, not only a browser tab.
- The difference from shadow IT lands at remediation, because revoking access cannot retract data a provider already holds.
- No single signal source sees the whole estate, so a shadow AI inventory is a merge of several consoles.
- A finding with no owner and no deadline stays undecided, so disposition needs four named outcomes and a service-level target.
- Orca discovers AI models and services across cloud accounts without agents, including shadow deployments, so the cloud half fills itself.
Shadow AI is any use of artificial intelligence inside an organization that no one approved, registered, or monitored. It covers consumer chat tools, AI features switched on inside approved software, desktop agents installed on laptops, and model endpoints running in unregistered cloud accounts.
That definition is settled ground. The subject here is the program that surrounds it. That program is an inventory record, a disposition decision, a set of controls, and a policy with artifacts in it.
One thing has changed since the category was first written about. Shadow AI now includes standalone agents running on a user’s own device and model endpoints inside your cloud accounts. Neither reaches the browser proxy that used to catch this.
What is Shadow AI?
The shadow AI meaning that matters operationally is narrower than the phrase suggests. A system counts when it touches company data or acts on company systems with no register, owner, or approval behind it. What shadow AI is and why it spreads is covered elsewhere, so what follows is a scoping test.
Where the Boundary Sits
Three questions decide it. A system is in scope when any one answer lands on the unmanaged side.
- Consumption or production. A team using a hosted model consumes AI. A team serving a model endpoint out of a cloud account produces it. Only the second leaves infrastructure behind.
- Standalone or embedded. A separate application is discoverable as software. A feature switched on inside a tool you already bought produces no install and no new invoice.
- Human-initiated or agent-initiated. A person at a chat window creates one session. An agent holding a credential creates traffic on its own schedule.
The third axis is the newest, and the vendors have caught up to it. Microsoft’s shadow AI documentation defines the category as “consumer-facing AI applications and standalone agents deployed across your organization without IT visibility or approval.” That page is still in public preview. It adds that “These agents can operate autonomously on user devices, creating blind spots in your security and compliance posture.”
Shadow AI vs. Shadow IT
The two diverge at the step that costs money: remediation. The shadow IT playbook runs discover, approve, onboard, and retire, and assumes risk ends when the asset goes. Shadow AI breaks that assumption at the last step. Shadow IT is an access problem you can close, and shadow AI is a disclosure problem you can only bound.
You can cancel a license and take the stored copy back. You cannot retract a prompt. Once text reaches a provider, its retention and training terms decide what happens next. That is why the approval question for an AI tool has to name data classes and not only the tool.
| Response step | Shadow IT | Shadow AI |
| What discovery finds | A distinct application, install, or invoice | A feature toggle, a token, or a workload that looks ordinary |
| What approval decides | Whether the tool may be used | Whether the tool may be used, and which data classes may reach it |
| What revocation undoes | Access, and the stored copy along with it | Access only. Data already sent stays under the provider’s retention and training terms |
| What evidence survives | Contracts, license records, and access logs | Whatever the provider chose to log, if you hold an account with it |
Access revocation behaves the same way on the identity side. Microsoft notes that removing a grant “doesn’t stop users from re-consenting to the application’s requested permissions.” Grants made through user consent cannot be revoked in the admin portal, only through the Graph API or PowerShell. So the response here needs a fourth step: what left, to whom, and under what terms.
Common Examples of Shadow AI in Organizations
Useful shadow AI examples are best grouped by the surface they run on, because that determines which control should have detected them. Each example below pairs the workload with the control that missed it.
- AI features inside approved SaaS. A vendor enables an AI feature in an existing SaaS tenant. The gate is vendor change management, which stays quiet because feature enablement is not a contract amendment. There is no new login and no new invoice.
- Desktop AI applications. An AI application installs on a laptop without touching a server. The gate is endpoint software inventory, and it depends on the device being managed. Microsoft’s preview list includes ChatGPT Desktop, Ollama Desktop, and Claude Desktop.
- Personal model API keys. A developer commits a personal API key to a repository. The gate is secrets detection, but ownership defeats it because no corporate console issued or can revoke the key.
- Cloud-hosted models. A model endpoint or notebook appears in an unregistered cloud account. The gate is cloud asset inventory. Both look like ordinary compute, and even the billing line appears as compute.
- OAuth grants for MCP servers or agent connectors. A user grants an OAuth scope to a Model Context Protocol (MCP) server or agent connector. The gate is app consent policy, and Microsoft notes that “By default, all users are allowed to consent to applications for permissions that don’t require administrator consent.”
Primary Risks and Security Concerns of Shadow AI
Grouping shadow AI risks into categories matters less to a security team than the questions it cannot answer while a system stays unregistered. Each question below has an owner, a source of truth, and a normal answer time once the system is in the register. Without one, every answer takes days and arrives as an estimate. None of the five is exotic, and all five become routine the moment a row exists.
- Which data classes reached which provider, under what contract, and with what retention and training terms?
- Who holds the credential, and what else does that credential open?
- Can the system take an action, or can it only read?
- What is the incident scope when the provider discloses a breach?
- What can you hand an auditor to show the answer above is complete?
The last question sets the price of the others. A registered system produces a record, and an unregistered one produces a reconstruction assembled from audit logs never designed to answer this. Knowing in advance which stores hold regulated data is what makes the first question answerable in hours. That is a data security posture management job, and it is this section’s real prerequisite.
How Shadow AI Happens in the Workplace
Shadow AI security starts at the gates. Every unregistered system entered through a path some control was meant to watch, and naming that path is more useful than naming a motive. Six paths reach a cloud estate. Each one carries the gate that should have fired and the reason it did not.
| Entry path | Gate that should fire | Why it stays quiet |
| A vendor enables an AI feature in a signed contract | Vendor change management | Feature enablement is not a contract amendment |
| A free tier never reaches procurement | Procurement threshold | The threshold is a spend figure and the spend is zero |
| One user approves a marketplace OAuth grant | App consent policy | The tenant default permits consent below the admin bar |
| An AI SDK arrives as a transitive dependency | Dependency review | The direct dependency passed and the client library came with it |
| A model is pulled into a container image at build time | Image provenance | The pull happens inside a step that produces a passing image |
| A personal account is used on a corporate device | Device policy | The application is permitted and the policy does not name the account |
The OAuth grant and the SDK key both end in a credential no human logs into. That is why the OWASP Non-Human Identities Top 10 reads as a shadow AI document, even though it does not use the term. A grant approved from an unmanaged network leaves a consent record and no network log at all. The free-tier path leaves no invoice either, so no renewal cycle ever surfaces it.
Order matters when you fix these. Start with app consent, since the approval queue it creates doubles as a discovery feed for everything that arrives next. Egress control comes second: it sees traffic without seeing ownership, and ownership is the field you need. The remaining four are worth fixing in whatever order your change calendar allows.
Detecting and Gaining Visibility into Shadow AI
Shadow AI detection produces a list, and this section starts where that list arrives. The hunt itself is covered in a detection framework for unapproved LLMs in cloud environments. What matters here is the record that hunt has to fill. An inventory row earns its place only when it can carry a decision.
- The system, named as vendor and product, or as cloud service and model.
- The surface it runs on: SaaS tenant, endpoint, cloud account, repository, or browser.
- The identity that authenticated it, and whether that identity is corporate or personal.
- The data classes it can reach.
- Whether it can take an action or only read.
- The owner, recorded as a person’s name.
- The date it was last seen.
The question of how to detect shadow AI then resolves into a smaller one. Which source fills which field, and what can that source not see? The third column below is the point of the table, because no source fills a row on its own.
| Signal source | Fields it fills | What it does not see |
| Identity provider app consent and OAuth grant logs | System, identity, scope granted | Anything reached through a personal account |
| SaaS admin and app governance consoles | System, surface, data classes inside that tenant | AI features the vendor never exposed as an admin setting |
| Network egress or DNS to model provider endpoints | System, date last seen | Unmanaged devices and off-network sessions |
| Cloud provider AI service inventories | System, surface, cloud identity | Models served from a plain VM or container |
| Repository scanning for provider SDKs and keys | System, identity, credential | Whether the key is still valid or what it has done |
| Endpoint software inventory | System, surface, date last seen | Personal and unenrolled devices |
| Expense and procurement records | System, owner | Free tiers, trials, and anything on a personal card |
That is the operational meaning of visibility here. A shadow AI inventory is a merge across five or six consoles, run on a schedule, with a stated date of last refresh. The refresh date is what makes the record defensible. Without it, a current inventory and a stale one look identical on the page, and the stale one fails the audit.
Managing and Preventing Shadow AI: Best Practices
Findings pile up when no decision attaches to them, so disposition is where a shadow AI program either runs or stops. The AI bill of materials tells you what exists, and the CISO approach to AI security strategy says who answers for it. The four options below decide what happens to each entry.
Deciding What to Sanction
Every system in the record gets one of four dispositions, and the criteria come from fields you already collected.
- Sanction. Contract and retention terms are in place, the data classes reached are permitted at that tier, and the credential is corporate.
- Sanction with conditions. The system becomes acceptable once one thing changes: a training opt-out, a narrower scope, a reissued credential, or a named owner.
- Restrict. The system stays for a defined group or use case, with the data classes it may reach written down.
- Block. The data class reached is prohibited, the action authority exceeds what a review would grant, or the vendor will not put terms in writing.
Give the decision a named owner and a service-level target. An undecided finding is the failure mode this program exists to prevent, so a finding older than the target becomes a reportable item.
Controls That Change the Default
Shadow AI prevention works by moving defaults, since a policy that depends on people reading it produces the estate you already have. Five controls do the moving.
- App consent policy set to admin approval for the scopes that matter, with a staffed approval queue behind it.
- Egress or DNS policy for model provider endpoints, applied to managed devices and to build systems.
- Key issuance through a managed path, so a provider key is a corporate credential you can rotate and revoke.
- Device policy covering standalone AI applications, which stops an install where the other controls only stop a connection.
- A procurement threshold that covers free tiers, which are the exact case a spend threshold was written to ignore.
Two of the five carry documented limits worth reading before you promise coverage. Microsoft’s built-in low-risk consent policy allows user consent only for apps from verified publishers and for permissions you classify as low impact. Microsoft’s shadow AI preview lists seven named agents, with detection available for all seven and blocking for exactly one. Blocking currently applies only to “managed Windows devices enrolled with Microsoft Intune,” and can take “anywhere from 15 minutes up to 8 hours” to apply.
Shadow AI tools, meaning the tooling that manages the problem and not the tooling that creates it, split into four categories. Those are identity and app governance consoles, SaaS security posture management, cloud AI inventory, and egress control. Treat the list as a coverage map against the signal table. No category reaches the whole estate, and none of them watches where data leaves for a model unobserved.
Shadow AI Governance and Policy Framework
A shadow AI policy becomes enforceable when it names artifacts instead of intentions. Seven items make it operable, and a policy missing any of them is a statement of position.
- Scope: which systems, which data, and which people it governs.
- Permitted and prohibited data classes, stated per tool tier so a new vendor inherits a rule.
- The approved register, with a named maintainer and an update cadence.
- An exception route, with an expiry date on every exception granted.
- A named decision owner per tier, so disposition never waits on a committee.
- A review cadence for the register and for the tier definitions themselves.
- Record retention, so the evidence outlives the tool.
An internal document is auditable only inside a management system that someone outside recognizes. ISO/IEC 42001:2023 is the international standard for an artificial intelligence management system, published in December 2023 and listed at stage 60.60, International Standard published. It gives the register, the owner, the exception route, and the review cadence a home an auditor already knows how to test. The CSA AI Controls Matrix v1.1 adds the control-level counterpart, with 247 control objectives across 18 domains and a published mapping to ISO 42001.
Four numbers tell you whether the program runs. Count new systems found this month, median time to disposition, exceptions past their expiry date, and registered systems with a named owner. Report the middle two even when they look bad: those are the ones that move. An existing security governance cycle is a better home for that report than a new AI committee.
How Orca Finds the AI Running in Your Cloud Accounts
Three of the five surfaces in this article sit outside what cloud-side discovery can reach. A desktop agent, a browser session on a personal account, and an AI toggle inside a SaaS tenant are endpoint and SaaS problems. Cloud-side scanning reads cloud accounts, so none of the three shows up there. The other two leave something in the cloud estate, and that is the half Orca fills.
Orca’s AI security posture management builds a complete AI inventory and bill of materials for every AI model deployed in your cloud, including shadow AI. It covers major provider services such as Azure OpenAI, Amazon Bedrock, SageMaker, and Google Vertex AI, inventories 50+ commonly used AI software packages, and detects exposed keys and tokens in code repositories. Collection runs through agentless SideScanning™, which adds cloud identity, exposure, and sensitive data context so unregistered AI systems appear with the information needed to assess risk. Get a demo to see which AI systems in your cloud accounts are running unregistered.
Frequently Asked Questions about Shadow AI
Does a Corporate AI Subscription Eliminate Shadow AI?
No. A tenant-wide subscription covers one vendor’s product reached through a corporate login. The same vendor’s consumer tier on a personal account sits outside it, as do AI features inside every other tool you already bought. Both keep producing findings after the rollout is called complete.
Who Owns the Shadow AI Register When There Is No AI Governance Function?
Give it to the team that already owns the asset inventory. The register is an inventory with extra fields, so the skills already exist. An interim owner beats waiting for an AI governance function to exist. The arrangement that fails is shared ownership, because a shared owner produces a queue and no decisions.
What Do You Do About an AI Feature a Vendor Turns On in a Contract You Already Signed?
Treat it as a change to an approved system. Check whether the feature is on by default, which data it processes, and whether it can be disabled at tenant level. Confirm the signed agreement covers the new processing. Then decide once, at the tenant level, and record the decision against the vendor so the next feature inherits the answer.
Is Blocking AI Tools at the Network Layer Effective?
It moves the usage rather than removing it. A proxy block on consumer AI domains pushes work onto personal devices and unmanaged networks. AI features inside approved SaaS stay untouched, and a model endpoint in your own cloud account is out of its reach entirely. The block also produces no record, which is the part an auditor asks for.
How Long Should a Shadow AI Finding Sit Undecided?
Pick a target, publish it, and treat a breach of that target as a finding in its own right. Set the number by the data class reached. A system that touched regulated data needs a same-week answer, and one that touched public content can wait for the monthly review. The number matters less than making an aging queue visible to whoever owns it.