Shadow AI Features: Auto-Enabled AI in SaaS

Shadow AI features are the AI capabilities your SaaS vendors turned on inside apps you already use, usually without a fresh security review, a contract amendment, or an admin who clicked enable. This is a wider category than the familiar one. The old picture of shadow AI was an employee pasting a customer list into a public chatbot. That still happens. But the bigger blind spot now is the assistant your vendor shipped in a Tuesday release note, reading the same corporate documents the parent app already read, because it inherited every permission that app held.

The definition shifted the moment enterprise vendors started shipping embedded AI as a default product feature rather than an opt-in add-on. Traditional shadow IT assumed a person made a choice: signed up, connected an account, uploaded a file. Vendor-enabled AI breaks that assumption. No tenant admin flipped a switch. No CISO signed a data processing agreement. The feature is sanctioned in the sense that the vendor is sanctioned, and shadow in the sense that no one at your company reviewed what it does, what it trains on, or where the data travels.

That gap is what configuration-based tools cannot close. They can read a vendor's settings page and report that a feature is on or off. They cannot tell you what the feature touched yesterday.

What counts as a shadow AI feature

• Copilot-style assistants embedded in productivity suites and email
• Summarization, smart reply, and auto-generated meeting notes inside collaboration tools
• Predictive scoring, lead enrichment, and case summarization inside CRMs
• Coding assistants embedded in developer platforms
• Agent connections a vendor exposes so third-party agents can call into the app on a user's behalf

Each of these acts as, or on behalf of, an identity that already has standing access to your data. That is the part a feature list will never show you.

Auto-enablement bypasses review because it enters through the product update channel, not the procurement channel. Your intake process was built to catch new vendors. It was never built to catch new features from vendors you already approved years ago.

The mechanism is plain. A vendor ships an AI capability. The feature is live at the tenant level unless a specific admin setting is flipped, and that setting often did not exist at your last contract review. The AI reuses the OAuth scopes your original integration granted, so it reads documents, calendars, messages, and records without triggering a new authorization prompt. Users see a new button. Security sees nothing new at all, because from the network's point of view the traffic still goes to a domain you trust.

This is where configuration and reality separate. The admin console shows a feature toggle in one of two states. It does not show which files the assistant read this week, which prompts carried regulated data, or which downstream tools the assistant called when a user asked it a question. The toggle is theoretical configuration. What the feature can actually reach is effective access, and the two diverge the instant the feature turns on.

Why the usual controls miss it

• Network and web gateways see traffic to a sanctioned domain and pass it through.
• Identity providers see a legitimate OAuth grant from months or years ago, still valid.
• Endpoint tools see the browser, not the feature switched on inside the browser.
• A zero trust policy trusts the parent app, and the AI feature rides that same trust.

The through-line is that every one of these controls anchors to a human user or a known app. The shadow AI feature is neither. It is a non-human identity operating with borrowed authority, which is exactly the machine insider category that no insider risk program was built to cover.

Detecting shadow AI features requires runtime signals, not configuration snapshots. A one-time console audit tells you what a vendor said was enabled last week. It cannot tell you what executed against your data yesterday, and it goes stale the next time the vendor ships an update.

Effective detection pulls from several sources at once:

1. API telemetry from each AI platform, to capture agent creation, invocation, and every tool call.
2. Browser-based signals, to catch prompts sent from managed devices, including prompts routed to personal accounts.
3. Identity graph correlation, to tie each agent back to its maker, its invokers, and the permissions it inherited.
4. An inventory of the agent connections a vendor exposes, so you can see which third-party tools can reach into the app.
5. Change detection on vendor defaults, to flag silent enablement inside a release cycle.

The reason this matters is scale. Agents move roughly sixteen times more data than a human does over the same period, and studies of deployed agents consistently find that close to ninety percent hold more permission than the workflow they run actually needs. A one-time audit against numbers like those is a photograph of a moving object.

Why a single control plane is the prerequisite

Chasing configuration signals across ten separate admin consoles is not a program. It is a spreadsheet that ages badly and disagrees with itself. The prerequisite for any shadow AI effort is one place that sees every platform where AI features run, so that one team can answer a simple question without logging into ten products: what AI is active, who owns it, and what identity does it act as. Fewer consoles to reconcile means fewer fire drills when an auditor or an incident asks for a straight answer.

Once a shadow AI feature is on the inventory, the next question is not whether it is configured to be safe. It is what the feature could actually reach right now. This is the move from theoretical configuration to effective access, and it is the whole game.

Effective-access triage asks three things about every feature:

1. What identity does the feature act as when a user invokes it? Very often that is a shared service account, not the person typing the prompt.
2. What can that identity read, write, or move? Not in the abstract, but as specific objects: which CRM records, which document libraries, which tables, which write actions.
3. What downstream systems does it connect to, directly or through a chain of tool calls, and what does each hop expand the reach to?

The point is to correlate an agent's real activity to its effective access inside the third-party app, rather than trust the vendor's settings page. A feature that looks harmless in configuration can carry critical blast radius once you map it to the actual service account it runs as and the objects that account can touch. A feature that looks alarming in the console may be neutered by an identity-level restriction the console never shows. Only runtime correlation resolves which one you are looking at.

Maker mode, chaining, and orphaned agents

Three patterns turn borrowed authority into real exposure. First, inherited privilege, where an assistant an admin configured runs with admin-level access even when a lower-privileged user invokes it. Second, action chaining, where one tool call triggers another and blast radius compounds at each step. Third, orphaned agents, where the person who created the feature has been deprovisioned but the agent keeps running on inherited credentials. The Salesloft Drift campaign tracked as UNC6395 showed how far this reaches: a single compromised integration cascaded through OAuth trust into roughly seven hundred organizations. None of those patterns is visible from a toggle.

Triage ends in one of three outcomes: approve with monitoring, restrict by scope or group, or block. Here the words have to be exact, because truth-in-labeling is the difference between a control and a claim. Block should mean the action does not complete, not that a checkbox is unticked and the vendor may re-tick it in the next release.

That distinction forces an honest statement about where each outcome is real today.

• Block at runtime, meaning an action is actually prevented as it happens, exists today for Claude and Microsoft Copilot only. On those platforms an enforcement decision can stop the call before it lands.
• For every other platform, including Agentforce, Snowflake Cortex, ServiceNow and Now Assist, Moveworks, Amazon Bedrock, Google Vertex, and workflow tools like n8n, the honest capability today is discover and govern: full visibility into what exists, what it can reach, and what it did, plus the evidence to drive a policy or configuration change. Autonomous runtime enforcement on those platforms is on the roadmap, not in the present tense.
• Obsidian is not an inline gateway sitting in the data path. It works as an Intel Inside decision engine: it supplies the runtime truth and the enforcement decision, and the platform that already sits inline carries it out.

Within that reality, the three outcomes read like this:

• Approve when the feature has a defined business use, its effective access sits within policy, and monitoring is in place to catch drift.
• Restrict when the feature earns its keep for some users but not all, and identity or data controls can hold the boundary. On platforms without runtime enforcement, restriction is applied through the vendor's own controls, informed by the evidence you gathered.
• Block when effective access exceeds policy and no scoping option closes the gap. On Claude and Copilot that block is enforced at runtime. Elsewhere it means disabling the feature through the vendor and verifying, with runtime evidence, that it stayed off.

Restriction is usually the right call. Blanket blocking breeds workarounds. Blanket approval breeds incidents. Restriction backed by runtime evidence is the defensible middle.

An audit trail for shadow AI features has to survive three things that native vendor logs handle badly: vendor updates, agent handoffs, and identity changes. Per-tenant, per-product logs are a starting point. They rarely connect the maker of an agent, the person who invoked it, the identity it acted as, and the data it actually touched.

A durable record captures all of that in one line of provenance: which feature ran, which identity invoked it, which service account it acted as, which specific objects and actions it reached, which downstream tools it called, and which policy decision applied. That record has to persist even when the vendor changes its logging format and even after a user's account is deprovisioned, because the questions arrive long after the event.

This is the operational layer that turns an auditor's request from a multi-week scramble into a same-day answer, and it is evidence that generates itself as agents work rather than evidence a team assembles by hand after the fact. Configuration tells you what a vendor intended. The audit trail tells you what actually happened, which is the only version that holds up.