Technical field guide · Edition 1.0 · August 13, 2026
Shadow AI Risk for Cyber Underwriters
What employee AI use actually looks like on a managed endpoint, what each access surface makes detectable, and, more usefully, what none of them can see. Written so that an answer on an application form can be interpreted rather than taken at face value.
This guide explains technology, not coverage. It makes no claim about what any carrier asks, requires, or prices. For the record of what is changing in the market, see the Cyber Insurance & AI Tracker.
Contents
Who this is for, and what it is not
This guide is written for people who assess AI risk but do not build endpoint software: underwriters, brokers, risk analysts, journalists covering the market, and the IT providers who have to answer for their clients. It exists because the two bodies of expertise involved rarely sit in the same place. Insurance professionals understand insurance. Endpoint security vendors understand endpoints, usually in large enterprises with security teams. The organizations most exposed to shadow AI are smaller than that and are frequently served by an outside IT provider.
The practical purpose is narrow: when an applicant writes “yes” next to a question about AI controls, this guide should let you work out what that yes can and cannot mean.
What this guide does
- Describes the mechanisms by which AI use becomes visible, generically rather than by product.
- States the blind spots of each mechanism plainly.
- Gives follow-up questions that distinguish a strong control answer from a weak one.
- Separates what is technically achievable from what is merely policy.
What it does not do
- Recommend a vendor, including us. Everything here is described in terms of mechanism.
- Assert what carriers ask or require. We have no underwriting data and do not speculate.
- Advise on coverage, pricing or claims. Those are outside our competence.
- Claim completeness. This is a description of the current landscape, and it is moving.
The five access surfaces
The single most useful idea in this guide is that “AI use” is not one thing. It arrives through at least five technically distinct paths, and a control that covers one may cover none of the others. When an organization says it monitors or blocks AI, the meaningful question is always on which surfaces.
The ratings below describe what is generally achievable with mature tooling on a managed device. They are not a rating of any particular product, and they degrade sharply on unmanaged devices, where most of them drop to nothing.
›AI websites used in a browser
#Generally detectable
An employee opens a browser and visits a general-purpose assistant, an image generator, a transcription service, or any of several thousand other AI web applications. This is the largest share of employee AI use in most organizations, and it is the surface people usually mean when they say "shadow AI".
How it becomes visible
- A managed browser extension observes navigation to a known AI domain, and can act before the page is used rather than reporting after the fact.
- DNS or secure web gateway logs show the domain was resolved or requested, which establishes that a site was reached but very little about what happened there.
- An endpoint agent can observe browser processes and, with a browser-level component, the specific tab and origin.
- Content entering the page — pasted text, typed prompts, uploaded files — is visible only to something running inside the browser session. Network-layer tooling sees an encrypted stream to a known host and nothing more.
What is missed
- New and obscure AI services that are not on whatever catalogue the tool maintains. Every detection approach here is fundamentally a list-matching problem, and the list is always incomplete. Treat any claim of complete AI site coverage with suspicion.
- AI features embedded inside sites that are not "AI sites" — a search engine that added an assistant, a CRM with a summarize button, a word processor with drafting built in. These do not look like AI destinations because they are not.
- Browsers that are not managed. A second browser installed by the user, or a portable one run from a USB stick or a downloads folder, carries no extension and is invisible to browser-level controls.
- Anything on a device the organization does not manage.
Evidence realistically available
Per-event records of which AI site was reached, by which user account, on which device, at what time, and what the configured control did about it. This is the strongest evidence available for any surface, but it is scoped to managed browsers on managed devices.
›Desktop AI applications
#Partially detectable
A locally installed application that talks to a model provider over its own network connection: the desktop clients the major providers ship, transcription and meeting-notes tools, coding assistants that run as an IDE or a standalone editor, and local model runners that execute a model on the machine itself.
How it becomes visible
- An endpoint agent can enumerate installed applications and observe running processes, which answers "is this on the machine" and "was it launched".
- Filesystem-level controls can prevent an executable from running at all, which is a blunt but reliable enforcement mechanism.
- Installation is often visible in the operating system's uninstall registry or its equivalent, so an inventory can be built without watching behaviour in real time.
What is missed
- What was actually sent. A desktop application making a direct API call does not traverse the browser, so a browser extension sees nothing, and the traffic is encrypted, so a network appliance sees a hostname at best. Prompt content is generally not recoverable from outside the application.
- Portable and single-file applications that require no installation and leave no registry entry. These run from a user-writable directory and are only visible if something is watching process execution.
- Locally-run models. A model executing entirely on the device may make no network request at all after download, so network-based detection has nothing to observe. The data never leaves the machine, which changes the risk but does not eliminate it — the machine is still an endpoint that can be lost, imaged, or exfiltrated from.
- Command-line tools and libraries invoked from a terminal or a script, which look like ordinary developer activity.
Evidence realistically available
A defensible inventory of which AI applications are installed and which were launched, plus a record of what was blocked. An organization should not claim it monitors the contents of desktop AI application usage unless it can explain the mechanism, because in the general case that is not technically available.
›Browser extensions with AI capability
#Partially detectable
An extension installed into the browser that adds AI functionality: writing assistants, summarizers, meeting recorders, autofill tools, and a long tail of small utilities. Extensions are unusual because they operate inside the page with the user's own session and permissions.
How it becomes visible
- Installed extensions can be enumerated by reading the browser profile, so an inventory is straightforward on a managed device.
- Enterprise browser policy can allow or block extensions by identifier, which is the most reliable control on this surface.
- Some extensions declare broad permissions — read and change all data on all websites — which is visible at install time and is a meaningful risk signal on its own.
What is missed
- What an extension does with page content once it is running. An extension with read access to a page can send its contents anywhere, and from outside the browser this is indistinguishable from ordinary browsing.
- Extension updates that change behaviour after review. An extension audited on Monday may ship a different payload on Friday, and this has repeatedly been the mechanism behind real incidents.
- Extensions in unmanaged browser profiles, including personal profiles signed into the same browser application alongside a work profile.
- Sideloaded or developer-mode extensions on devices where that has not been restricted.
Evidence realistically available
An inventory of installed extensions with their identifiers and permission scopes, and a record of policy decisions. Behavioural evidence about what an extension transmitted is generally not obtainable.
›OAuth-connected AI
#Partially detectable
A third-party AI application that an employee authorizes to access a corporate account — typically a productivity suite — using OAuth. The user clicks "allow", and thereafter the application holds a token that lets it read mail, files, calendars or chat without the user being present. This is the surface most often missed entirely, because nothing is installed and nothing is browsed.
How it becomes visible
- The identity provider records the grant. Enumerating consented applications and their scopes is the reliable detection method, and it is an administrative query rather than an endpoint one.
- Scope strings are informative: an application holding permission to read all mail in the tenant is a materially different exposure from one holding permission to read a single user's profile.
- Administrators can restrict user consent so that new grants require approval, which converts an invisible risk into a queue.
What is missed
- What the application did with the access. Once a token is issued, activity appears in provider audit logs as application activity, and reconstructing what was read and where it went is limited by whatever logging tier the organization pays for.
- Grants against accounts outside the managed tenant, including personal accounts holding work data.
- Applications that are not recognisably AI. The grant record shows a name and a set of scopes, not whether a model is behind it.
- Endpoint tooling of any kind. This surface is invisible to endpoint agents and browser extensions, because the data path never touches the employee's device. An organization relying solely on endpoint controls has no coverage here at all.
Evidence realistically available
A point-in-time inventory of consented applications, their scopes, who granted them and when, plus whatever the identity provider retains. This is genuinely good evidence for the existence and scope of access, and weak evidence about its use.
›Embedded AI in software the organization already licenses
#Largely undetectable
AI features added to tools already in use and already approved: assistants in productivity suites, summarization in a ticketing system, drafting in a CRM, code completion in a developer platform. Nobody installed anything and nobody visited an AI site. The feature arrived in an update.
How it becomes visible
- Licensing and tenant configuration establish whether a feature is enabled, which is an administrative fact rather than a detection.
- Some vendors expose their own usage reporting for their AI features, at varying granularity.
What is missed
- Essentially everything else, from an external vantage point. Traffic to the vendor is traffic the organization already permits and expects, and it is indistinguishable from ordinary use of that product.
- Which data the feature processed, where it was processed, and whether it contributed to model training, all of which are governed by the vendor contract rather than by anything the organization can observe.
Evidence realistically available
Contractual and configuration evidence: what is licensed, what is enabled, what the vendor commits to. This is a vendor-management question, not a monitoring question, and it should be answered as one. An organization claiming to "monitor all AI use" while embedded AI is enabled across its estate is making a claim it cannot support.
›Agentic AI and tool-connected assistants
#Largely undetectable
An assistant that does not only generate text but takes actions: browsing, calling APIs, reading and writing files, or operating other software on the user's behalf. This includes agent-capable browsers, assistants connected to local tools through emerging protocols, and automation platforms with a model in the loop.
How it becomes visible
- The agent still has to run somewhere. If it runs as a local application or a browser, the surfaces above apply to its presence, if not to its behaviour.
- Actions taken against systems that log well — an identity provider, a source control system, a cloud platform — appear in those systems' logs, attributed to whatever credential the agent used.
What is missed
- The relationship between an instruction and an action. Logs show that a credential did something; establishing that a model decided to do it, and why, generally requires instrumentation inside the agent.
- Agent-capable browsers that carry their own automation and do not accept conventional management or extensions.
- Actions taken with a credential the agent was legitimately given, which look exactly like the authorized user acting.
Evidence realistically available
Weak, and honestly so. This is the least mature surface for monitoring, and the gap between what questionnaires increasingly ask about agentic AI and what any organization can technically evidence is currently wide. An underwriter should expect uncertainty here and should be suspicious of confident answers.
Personal versus corporate AI accounts
This distinction does more work in risk terms than almost anything else on this page, and it is routinely collapsed. Two employees can use the same AI product on the same day with entirely different consequences, because the account determines the contract, the data-handling terms, the retention, whether the organization has any administrative visibility, and whether it can retrieve or delete anything afterwards.
Corporate account
- Covered by a commercial agreement, usually with defined data-handling and training terms.
- Administrative visibility into membership, and often some usage reporting.
- Conversations and uploads are, in principle, within the organization's control.
- Can typically be tied to corporate identity and revoked on offboarding.
Personal account
- Governed by consumer terms between the vendor and the individual, not the organization.
- No administrative visibility, no export, no deletion right the organization can exercise.
- Survives offboarding entirely. The data remains in an account the organization cannot reach.
- Often the same product, the same interface, and the same browser, which is why users do not perceive a difference.
Why detection is harder than it sounds
From outside the session, both accounts look identical: the same domain, the same encrypted connection, the same process. Distinguishing them requires observing the authenticated session itself — which identity is signed in — and that means something running inside the browser, or enterprise sign-on enforcement that makes the personal path unavailable in the first place.
The practical consequence for anyone assessing an application: “we have an enterprise subscription” answers a procurement question, not a control question. The control question is what happens when an employee opens a second browser profile.
How sensitive data actually reaches AI tools
Exposure is rarely dramatic. In most cases someone is doing their job: summarizing a document, rewriting a client email, debugging code that contains a connection string, turning a spreadsheet into a chart. The data reaches the tool through one of five input paths, and the paths differ substantially in how amenable they are to inspection.
| Input path | Inspectability | The catch |
|---|---|---|
| Paste | Good | Requires something in the session. Clipboard content is a discrete event with a clear boundary, which makes it the most tractable path. |
| Typing | Moderate | No natural event boundary, so detection is inherently noisier. Sensitive material typed slowly and in fragments is harder to recognise than the same text pasted at once. |
| File upload | Moderate | File name and type are usually visible; inspecting contents means parsing arbitrary formats, and archives and encrypted files defeat it. |
| Images and screenshots | Poor | A screenshot of a patient record is, to a text classifier, an opaque blob. This is a significant and underappreciated gap, and it is trivially available to any user. |
| Connected data | Poor | Where the tool holds a token to read a mailbox or a drive directly, no content passes through the employee's device at all. See the OAuth surface above. |
On classifier accuracy
Content inspection works by pattern matching, sometimes with a checksum or validation step. Structured identifiers with check digits — payment card numbers, some national identifiers — can be recognised with high precision. Unstructured sensitivity — a confidential strategy document, an unreleased financial figure, a client name that is itself the secret — generally cannot, because there is no pattern to match.
This matters when interpreting an answer. An organization saying it blocks sensitive data from AI tools is usually saying it blocks recognisable sensitive data. The material most damaging to that particular business is often exactly the material no classifier can identify.
Reading questionnaire answers
Applications ask short questions about controls that have long technical answers. The result is that the same word covers very different realities. Below are five common questions, the answer usually given, what it can technically mean, and the follow-ups that separate a substantiated control from an aspiration. None of this implies any carrier asks these exact questions; they are the recurring themes, phrased plainly.
›"Do you monitor employee use of generative AI?"
#
The answer usually given
Yes.
What it can technically mean
On its own this answer carries almost no information, because "monitor" spans everything from a firewall log showing a domain was contacted to a per-event record of what an employee pasted into a specific tool. Two organizations can both answer yes and differ by an order of magnitude in what they could actually produce after an incident.
Questions that resolve the ambiguity
- Which surfaces? Browser sites, desktop applications, extensions, OAuth grants, embedded features — coverage typically differs sharply between them.
- At what layer? Network, endpoint, or inside the browser session. This determines whether content is visible or only destinations.
- On which devices? Managed only, or does the estate include unmanaged and personal devices.
- Retained for how long, and can a record be produced on request?
›"Do you block unauthorized AI tools?"
#
The answer usually given
Yes, we block them.
What it can technically mean
Blocking is real but it is never total, and the honest version specifies the mechanism, because each mechanism fails differently. Domain blocking fails against new domains. Application blocking fails against portable executables. Extension policy fails against unmanaged browsers. An organization that says "blocked" without qualification is describing an intention rather than a control.
Questions that resolve the ambiguity
- Blocked by what mechanism, and what defeats that mechanism?
- Is it deny-by-default with an approved list, or a blocklist of known tools? These have very different failure modes: a blocklist is always behind.
- What happens when a user encounters a block — is it recorded, and does anyone review it?
- Are there exceptions, and who can grant them?
›"Do you maintain an inventory of AI tools in use?"
#
The answer usually given
Yes, here is our approved tools list.
What it can technically mean
An approved list is a statement of policy. An inventory is a statement of fact, and the two are frequently very different, which is the entire reason shadow AI is a category. The useful question is how the inventory was produced: self-declaration, a survey, or observation.
Questions that resolve the ambiguity
- Was the inventory built by asking people, or by observing what runs?
- Does it include tools that are in use but not approved? An inventory that lists only approved tools is a policy document.
- When was it last refreshed, and by what process?
- Does it cover OAuth-connected applications and embedded AI features, or only browsed and installed tools?
›"Do you prevent sensitive data being entered into AI tools?"
#
The answer usually given
Yes, we have DLP.
What it can technically mean
Prevention at the point of entry requires something inside the session where the typing and pasting happens. Traditional data-loss tooling built for email and file transfer generally does not see a paste into a web application. Where content inspection does exist, it works on pattern matching, which has both false positives and false negatives, and its coverage varies by data type.
Questions that resolve the ambiguity
- Which input paths are covered: paste, typing, file upload, images and screenshots? Screenshots in particular defeat most text-based inspection.
- Which data classes are actually enabled, and which are turned off?
- Is it blocking or only recording? Both are legitimate answers, and they are different answers.
- What is the failure mode when the inspecting component is not running?
›"Do employees use personal AI accounts for work?"
#
The answer usually given
No, we provide an enterprise account.
What it can technically mean
Providing an enterprise account and preventing personal account use are different controls, and the first does not imply the second. The same person can be signed into a corporate assistant in one browser profile and a personal one in another, on the same machine, within the same minute. Distinguishing them requires visibility into the authenticated session, not merely into the destination.
Questions that resolve the ambiguity
- How is the distinction technically established — session inspection, enterprise sign-on enforcement, or an assumption?
- Is personal-account access blocked, recorded, or neither?
- Does the enterprise agreement actually cover the tools people are using, or only some of them?
Structural blind spots
These are not gaps in any particular product. They are properties of the problem, and they apply to every approach on the market, including ours. An assessment that assumes they can be closed by buying something will be wrong.
Unmanaged and personal devices
Endpoint and browser controls exist only where they are installed. An employee's home computer, personal phone, or a contractor's own laptop carries none of them. If work data can reach a personal device — and where webmail or a browser-accessible file store exists, it usually can — then there is a path to any AI tool that no endpoint control observes. The size of this gap is an organizational fact, driven by device policy and remote-work practice, not a technical one.
Attribution
Records are attributed to whatever identity the observing layer can see, and the layers disagree. An endpoint sees an operating-system account. A network appliance sees an IP address. An identity provider sees a directory principal. Reconciling these into “this person did this” is reliable on a single-user managed workstation and progressively less reliable everywhere else: shared workstations, kiosk and clinical environments, terminal servers and virtual desktops, and any device where several people use one local account.
A second, quieter attribution problem: activity that cannot be tied to a specific known AI tool. Traffic to an unrecognised destination may be an AI service, or may not. Systems handle this differently, and whether such activity is counted, dropped, or reported separately materially changes any number derived from it.
Catalogue completeness
Identifying AI tools depends on knowing what they are. Every approach ultimately compares observed activity against a maintained list of domains, executables, extension identifiers or application names. New tools appear continuously, and the list is always behind. A deny-by-default posture, permitting only an approved set, avoids this problem structurally, at the cost of friction that many organizations decline to accept. When an organization operates a blocklist, its coverage is bounded by someone else's research cadence.
Retention windows and the shrinking past
Evidence exists only for as long as it is retained, and retention is usually shorter than people assume when they answer a question about audit trails. There is a related trap: records tied to devices can degrade when devices are decommissioned, so a historical count can legitimately shrink over time. Anyone relying on a figure describing a past period should establish what it is a count of, and whether the same query would return the same number today.
Configuration is a point in time
A statement that a control is enforced describes the moment it was made. Controls are loosened for a project and not restored, suspended during an incident, or scoped to exclude a group that complained. Without a change history, “we block AI tools” cannot be evaluated for the period that actually matters, which is the period before the loss.
What an IT provider can and cannot attest to
Most smaller organizations do not answer these questions themselves. An outside IT provider does, or helps. That makes the provider's scope of knowledge part of the risk picture, and it is worth being precise about, because the gap between what a provider is asked to confirm and what it can actually observe is where professional liability accumulates.
Can reasonably attest to
- Which controls it configured, with what settings, and when those settings changed.
- Which devices its tooling reached during a stated period.
- What its tooling recorded on those devices: tools observed, actions taken, alerts raised.
- Which applications and extensions are installed on managed devices.
- Which third-party applications hold OAuth grants in a tenant it administers, and their scopes.
Cannot reasonably attest to
- Activity on devices it does not manage, including personal and contractor equipment.
- That an inventory is complete, since catalogue coverage is inherently partial.
- What employees did inside applications that expose no telemetry.
- Whether staff were trained, unless it delivered the training and holds the records.
- That a policy document reflects actual practice. It can attest to enforcement, not to culture.
- Anything about a period before its tooling was deployed.
The scoping sentence
The most useful thing a provider can supply alongside a yes is the scope of that yes. A statement of the form below is more defensible than an unqualified affirmative, and more useful to whoever is assessing it:
“AI tool access is monitored on [N] managed Windows endpoints via [browser extension / endpoint agent], covering browsed AI sites, installed AI applications and browser extensions, from [date]. OAuth-connected AI applications are reviewed [frequency] in the [tenant]. Unmanaged and personally-owned devices are out of scope. Records are retained for [period].”
An assessor reading that knows exactly what has been claimed. An assessor reading “Yes” does not, and neither, in many cases, does the person who wrote it.
Practical realities below 500 seats
Most published guidance on AI governance assumes a security function: a team to tune policies, review alerts, and run an exception process. A 40-person firm has none of that, and the guidance does not degrade gracefully. Four consequences are worth knowing when assessing organizations of this size.
Nobody is reading the alerts
Detection produces a queue, and a queue requires an owner. Where there is no security function, the practical choice is between controls that act automatically and controls that generate a record nobody reviews. The second still has value after an incident, but it prevents nothing. It is worth distinguishing whether a control blocks or merely records, and if it records, who looks.
Blocking has a business cost that gets it reversed
Restrictive controls generate complaints, and in a small organization the complaint reaches the decision maker within a day. Controls deployed in enforcement mode without an approved alternative tend to be loosened quickly. This is why a change history matters more than a snapshot: the interesting question is not what is configured today but whether it survived contact with the business.
The estate is mixed and partly unmanaged
Smaller organizations more often have personal devices doing work, contractors on their own equipment, and a long tail of machines that were never enrolled. Coverage claims should be read against the total headcount rather than the managed device count, and the difference between those two numbers is often the most informative thing available.
Enterprise breach statistics do not transfer
The widely-cited figures on shadow AI cost and prevalence are drawn overwhelmingly from large organizations, and frequently from network or data-loss vantage points that small organizations do not have. Applying them to a 40-person company imports assumptions about record volume, regulatory exposure and detection capability that do not hold. The direction of those findings is probably right. The magnitudes are not transferable, and should not be used as if they were.
Common questions
What is shadow AI?
Shadow AI is employee use of AI tools that the organization has not approved and often does not know about. It differs from shadow IT in one way that matters for risk: the tools process organizational data as their normal mode of operation, so use and data exposure are the same event rather than sequential ones.
Can an organization detect all employee AI use?
No. Coverage varies sharply by surface. Browser-based AI on managed devices is generally detectable; OAuth-connected applications are detectable administratively; desktop applications are detectable as installations but usually not as content; embedded AI features inside licensed software and agentic AI are largely not detectable by monitoring at all. Any claim of complete visibility should be treated as a claim about intent rather than capability.
What does "blocking AI" technically mean?
It usually means one of four things: refusing to resolve or route to a domain, preventing an executable from running, refusing to load a browser extension, or intercepting content before it is submitted within a page. Each is defeated by a different workaround, so the mechanism matters more than the word. No mechanism is complete on its own.
What evidence can an organization realistically produce about AI use?
On managed devices with browser-level controls: per-event records of which tool was reached, by which user, when, and what the control did. Administratively: an inventory of OAuth grants and their scopes, and a list of installed applications and extensions. Configuration history showing what was enforced and when. What is generally not producible is the content of desktop application sessions, the behaviour of a browser extension, or any activity on unmanaged devices.
What can a managed service provider attest to about a client's AI use?
An MSP can reasonably attest to what it configured, when it changed, and what its tooling recorded on the devices it manages. It cannot reasonably attest to activity on unmanaged or personal devices, to what employees did inside applications it has no visibility into, or to the completeness of any AI tool catalogue. Attestations that exceed the deployed telemetry are the ones that create liability for the provider.
Does an enterprise AI subscription solve shadow AI?
It addresses the contractual and data-handling risk for the tool it covers, which is meaningful. It does not prevent the same employee using a personal account for the same task, and it does not cover the long tail of other AI tools. Sanctioning a tool and controlling access to alternatives are separate controls.
About this guide
Written and maintained by the ShadowLock research team. We build endpoint and browser controls for employee AI use in organizations managed by IT service providers, which is the basis for the technical description here and also the reason to read it critically: we work on one part of this problem and describe it from that vantage point.
Nothing in this guide asserts what any insurer asks, requires or prices, because we have no underwriting data and it would not be ours to claim. Where the guide describes limitations, those apply to our own approach as much as to anyone else's.
Edition 1.0 · Published 2026-08-13 · Corrections and disagreement from people who work in this market are welcome and genuinely useful. Reach us via the contact page.
Part of the Cyber Insurance & AI research hub
This guide explains the technology. The tracker records the market.
For dated, primary-sourced entries on affirmative AI endorsements, exclusion filings, subrogation against IT providers, and the questions appearing on applications, see the tracker. Each entry carries its source, the date it was added, the date it was last verified, and whether it is confirmed, reported or commentary.
Cyber Insurance & AI Tracker →