A practitioner breakdown of Shadow AI across five operational surfaces, built from direct fleet telemetry and real-world exposure patterns. The focus is on how these systems operate in practice, where control boundaries fail, and how risk accumulates outside visibility in active environments.
This blog post is part of the MSPs Innovation Series.
Why MSPs cannot ignore Shadow AI?
For an MSP, every customer tenant is a liability surface. Shadow AI is the fastest-growing one, and unlike traditional shadow IT, it doesn’t show up on a network device list, doesn’t trigger an EDR alert, and doesn’t require malware to exfiltrate data.
Shadow AI as a problem space spans a few distinct surfaces.
No Slack account needed.
The MSP-specific risk model
Consent is a permanent data egress. When an end-user clicks “Accept” on an OAuth prompt for an AI app, they grant a long-lived token that reads Mail/Files/Calendar without a password, without MFA, and without traversing any Conditional Access policy that lacks the workload-identity condition. The token survives password resets. The MSP’s CA stack does nothing about it.
Liability now flows through the MSP, not just the customer. Cyber insurance carriers, SOC 2 auditors, and HIPAA covered-entity attestations increasingly ask: “Do you know every third-party application with access to client data?” If a cursor.ai consent for a customer tenant was granted six months ago and the vendor later breaches, the carrier reviews the MSP’s documented controls. “We didn’t know” is not a defensible answer in 2026.
Velocity outpaces manual review. A typical 300-seat SMB tenant accumulates 5-25 net-new AI-related OAuth grants per quarter, mostly self-service. At 100 customer tenants, that’s 500-2500 new consent events per quarter, orders of magnitude beyond what a Tier 1 analyst can review by hand.
Cross-tenant blast radius is real. A multi-tenant AI vendor compromise (a Cursor-shaped company gets popped) impacts every customer who consented simultaneously. The MSP discovers the impact one tenant at a time, alphabetically, while the attacker has already drained inboxes in parallel.
Regulatory bodies treat AI vendors as subprocessors. GDPR Article 28, HIPAA BAAs, SEC Reg S-P, and Australia’s Privacy Act amendments all require subprocessor inventory. Every AI OAuth grant is a subprocessor relationship that the customer didn’t know they signed. The MSP is the only party positioned to surface it.
The token is the data. Unlike phishing-stolen creds (which trigger MFA, sign-in risk, impossible-travel signals), AI-tool tokens look like every other legitimate app. There is no “anomalous sign-in” to alert on the access is the design.
The Approach of Shadow AI
Any serious attempt to manage Shadow AI begins with taxonomy, not tooling. Without a shared and defensible model, detection logic fragments, response becomes inconsistent, and regulatory alignment fails under audit pressure. In controlled environments, undefined scope is treated as an unmanaged risk.
Shadow AI is not a discrete category. It is a distributed condition that emerges across multiple control planes. Collapsing it into a single label obscures exposure paths, weakens enforcement, and creates a false sense of assurance. Field observations show consistent manifestations across five primary surfaces, each with distinct telemetry requirements, control boundaries, and audit expectations.
These surfaces are operationally independent. They are instrumented differently, governed through separate policy frameworks, and reviewed by different functions across security, compliance, and audit. Controls do not translate cleanly between them. What is sufficient at one layer may be nonexistent at another.
A governance model that does not explicitly enumerate and address all five surfaces is structurally incomplete. It will degrade under real conditions and fail against regulatory scrutiny. Coverage that appears comprehensive in design quickly fragments in execution.
Insight: an attacker compromises one mid-tier AI vendor and inherits permissions across thousands of tenants instantly. The defender (the MSP) reviews one tenant at a time. The only way to close this gap is an automated, continuous, fleet-wide consent inventory, which is exactly the problem this script begins to solve, but at the wrong scope.
The Shadow AI Types
Shadow Endpoint
Local AI execution is the most immediate and consistently observed surface. Desktop AI tooling is now standard across SMB fleets, deployed outside procurement channels, and often without security awareness. Common artifacts include Claude Desktop, Cursor, Perplexity Comet, GitHub Copilot Desktop, and local inference frameworks such as Ollama and LM Studio. These applications operate directly on enterprise endpoints and interact with sensitive data in real time.
Visibility is entirely dependent on endpoint telemetry. Effective detection requires binary-level inventory, process execution monitoring, and behavioral correlation tied to user context. Even in environments with mature EDR, a lack of explicit coverage for AI tooling results in partial visibility. In unmanaged or lightly managed fleets, this surface is effectively unmonitored.
Shadow Identity
This surface addresses actual usage of sanctioned AI, not entitlement. Therefore, licensing data does not reflect exposure. Risk is determined by who is invoking AI capabilities, within which workflows, and against which data sets.
Microsoft Copilot provides a clear case. Deployment may be broad, but usage concentrates around specific roles and functions. High-frequency interaction with sensitive data domains creates localized risk clusters that are invisible in aggregate reporting. Assumptions that enablement equals adoption, or that adoption is uniform, do not hold under inspection.
Visibility depends on audit telemetry correlated with identity and activity context. Without this linkage, organizations operate under the false assumption that enablement equals adoption, and that adoption is evenly distributed. In practice, neither holds true.
Shadow Infrastructure
This surface captures how AI capability is wired into the environment through integrations, network paths, and execution models across M365 and GWS. It includes OAuth-based integrations, third-party applications, and any service that establishes a control or data path between enterprise systems and external AI providers.
At the network layer, this surface is expressed through egress to inference endpoints. API calls to model providers, plugin backends, and embedded AI services create outbound flows that carry prompts, context, and potentially sensitive data. DNS and flow telemetry provide partial visibility, but attribution to user and workload often requires correlation with identity and application logs.
A distinct category within this surface is local inference traffic. Models executed on the device generate no external network signal by design. There is no egress, no API call, and no perimeter artifact to inspect. This class of activity bypasses traditional network controls entirely, rendering perimeter-based detection ineffective. Visibility reverts to the endpoint, or it does not exist at all.
Shadow OAuth
This surface is defined by third-party AI applications that have been admin consented into Microsoft 365 or Google Workspace environments, often through routine approval workflows that receive little scrutiny at the time of authorization. In many cases, these approvals occur months before any formal security review, yet they persist as durable tokens with ongoing access to Graph or Directory resources.
The access granted through this model is fully legitimate within the platform’s trust framework, which is precisely what makes it difficult to detect and control. A single consent action can authorize extensive permission scopes, including access to mailboxes, files, calendars, and user data. Over time, these tokens become embedded within the environment as invisible infrastructure, rarely revisited and even less frequently revoked.
The associated risk is structural rather than hypothetical. These applications operate with delegated or application-level permissions that often extend beyond the visibility of traditional endpoint or network controls. Effective oversight depends on continuous analysis of consent events, granted scopes, and token activity. Without this level of scrutiny, the surface remains persistently exposed, even when operating entirely within expected platform behavior.
Shadow Agent
This surface represents the emergence of nonhuman actors operating within the environment through AI-driven workflows and agent frameworks. It includes Copilot Studio workflows, Entra Agent ID workload identities, and Model Context Protocol bridged clients. These entities are provisioned to operate autonomously or semi-autonomously, executing tasks across systems based on predefined logic, prompts, or external triggers.
Each agent carries its own identity, distinct from the user who created or authorized it. That identity is bound to a defined privilege envelope, often spanning multiple services and data sources. Over time, these agents accumulate access and operational scope, effectively becoming persistent actors within the tenancy.
What differentiates this surface is not just access, but behavior. Agents can initiate actions, retrieve data, and interact with services without continuous human intervention. Their activity is logged, but the volume and complexity of these audit trails often exceed what is practically reviewed. As a result, these logs exist more as a theoretical control than an operational one.
The risk is driven by the combination of autonomy, privilege, and limited oversight. Without clear governance over identity lifecycle, permission scoping, and behavioral monitoring, these agents introduce a class of activity that does not align with traditional user or service account models, yet has a comparable or greater impact.
Tip. Walk every client briefing through all five types in this order. Even when only two apply, the act of enumerating the negatives (“we audited, and no Ollama runtime was found on any managed endpoint”) is itself a defensible artifact at the next insurance renewal.
From the Shadow AI Trenches
Fourteen days inside active SMB environments is sufficient to move Shadow AI out of theory and into measurable reality. What emerges is not sporadic misuse, but consistent, patterned behavior across users, devices, and services. As we know it, the signal is clear once the right telemetry is aligned.
Endpoint shows rapid adoption of desktop AI tooling, often within days of release. Installation paths bypass standard software channels, landing in the user space with no administrative visibility. Execution patterns indicate frequent interaction with local files, clipboard data, and browser sessions. In multiple cases, sensitive material is staged and processed through these tools without any corresponding audit trail at the network or SaaS layer.
Identity contradicts licensing assumptions. A small subset of users accounts for the majority of AI interactions. These are not always technical roles. Operations, finance, and customer-facing functions show concentrated usage, often tied to high-value data workflows. The exposure is not evenly distributed, and it is not aligned with expected risk models.
OAuth surfaces long-standing integrations with broad access scopes. Many were approved months prior to inspection and remain active without review. Token usage confirms ongoing access to mail, files, and user data, often unrelated to current business needs. These integrations operate within expected platform behavior, which is why they persist undetected.
Shadow Infrastructure Components
The network beacon leads with many events, indicating persistent communication with external AI infrastructure. This pattern reflects established, ongoing data exchange that operates without attribution or control. It is continuous, low-friction, and largely invisible to standard monitoring practices.
Browser AI usage is followed by hundreds of events from specific tenants interacting with Chinese AI services. This activity blends into normal web traffic while exporting prompts and contextual data beyond organizational boundaries. It is not anomalous from a network perspective, which is precisely why it persists.
Ollama traffic appears limited at dozens of events across a few hosts, but this is a visibility artifact. Local inference generates no network telemetry. Once deployed, execution is silent, bypassing perimeter controls entirely.
The highest impact finding is not volume. Azure OpenAI and Azure Machine Learning instances were identified across three tenants, provisioned without governance, and billed internally. These are sanctioned platforms operating outside sanctioned control.
Chinese AI Infrastructure Fingerprint
Another potential exposure is intentionally difficult to identify through conventional detection methods. What appears as routine outbound traffic resolves into a concentrated pattern once domain-level inspection and correlation are applied.
DeepSeek activity does not surface through its own brand indicators. Instead, it routes through shared domain families such as volces and bytedns. This indirection is not accidental. It obscures attribution and undermines controls that rely on simple domain matching or allowlists. From a defender’s perspective, the signal is present but mislabeled.
ByteDance Doubao follows the same infrastructure path, reinforcing the idea that this is not a single-service pattern but a shared operational model. Multiple AI providers are leveraging overlapping delivery layers, making isolation and enforcement significantly more complex. Blocking at the surface risks collateral impact, while allowing it permits continued data movement.
Beyond these, a distributed set of providers across Tencent and adjacent ecosystems forms a persistent background layer. Individually low visibility, collectively meaningful.
Closing
Shadow AI is not a single tool, a single policy, or a single detection rule. There are a few surfaces, each visible to a different sensor and invisible to at least one product in the current stack. Restricted data is the regulatory overlay that turns any one of them into an audit event. The MSPs who capture the next months of market opportunity are those treating Shadow AI with the same operational discipline that captured Shadow IT in 2015. Inventory first, governance second, enforcement third, and monetize all three.
Tools and Blog Posts
Check the Shadow AI Audit tool for Microsoft 365
More insights, tips, and blog posts in the Guardz Blog
