Personal AI Accounts Carry 67% of the AI Use on Your Corporate Devices

45% of employees are now regular AI users on corporate devices, against 15% a year earlier. Two thirds of them sign in with an account your organisation does not administer. The most common thing they upload is not customer data or marketing copy. It is source code. Your data loss controls were built for a perimeter that this traffic walks straight past.

The short answer

Verizon's 2026 breach report found 45% of employees are regular AI users on corporate devices, and 67% of them sign in with non-corporate accounts. Source code is the most uploaded data type. The control that works is workspace restriction on a managed browser, not a domain block.

What the 67% figure actually counts

The number is being quoted as though 67% of employees use AI on personal accounts. That is not what was measured, and the difference matters when you brief a board.

Verizon's 2026 Data Breach Investigations Report reports two figures. 45% of employees are regular AI users on corporate devices, up from 15% in the prior edition. Of those users, 67% reach AI services from non-corporate accounts.

Multiply the two and you get about 30% of the workforce operating AI through an account your identity provider never issued. That is the honest version. It is smaller than the headline and it is still the largest ungoverned data path most security teams have.

The denominator moved faster than the policy

Tripling in twelve months is the part that breaks planning assumptions. A control designed against 15% adoption was sized for an exception. At 45% it is sized for the default case, and the two need different architectures.

Shadow AI is now the third most common non-malicious insider action in the report's data loss dataset, a fourfold increase year on year. Your users are not attacking you. They are working, in the fastest way available.

Source code goes out first

The 2026 report analysed 858,440 data loss prevention events involving uploads to generative AI tools. It is the largest dataset the report has used on this question. Ranked by frequency, source code came first by a wide margin, followed by images and structured data.

That ordering should reset your priorities. Most AI acceptable use policies were drafted by privacy teams and read as though the risk is customer personal data. The measured risk is your codebase.

Why code leaves before anything else

Code is the work product with the tightest feedback loop. A developer pastes a failing function, gets a fix in 20 seconds, and verifies it immediately. Nothing else on a knowledge worker's desk pays back that fast.

Code is also the easiest thing to move. It is plain text, it copies cleanly, and it carries no obvious personal data marker, so the classifier watching for names and card numbers stays quiet. The developer feels compliant because no customer record moved.

The economics behind that behaviour sit in the comparison of the three scoreboards used to judge AI coding tools, and the tool-level differences in the verdict on Claude Code, Cursor and Copilot.

What one paste actually exposes

A single function is rarely the loss. The context around it is. Internal service names, environment variable keys, table schemas, queue topics and the shape of your authorisation logic all travel in the same block.

Trade secret protection depends on taking reasonable steps to keep the secret. A paste into an account with consumer training defaults is hard to describe as a reasonable step after the fact. That is a legal exposure created by a routine engineering action.

I would treat the code paste as the primary loss event and everything else as secondary. If your programme protects one category properly this quarter, make it that one. Teams weighing how much code to expose at all will find the trade in the build versus buy analysis for coding agents.

The perimeter did not fail, it was never in the path

Traditional data loss prevention watches egress points you own. Mail gateways, managed file shares, endpoint copy events to removable media. A chat session over TLS to a consumer domain is none of those things.

The interaction also looks like ordinary browsing. There is no attachment, no recipient, no transfer. The user types, and the classifier sees a request body it cannot inspect unless you have already decided to inspect it.

So the failure is architectural rather than operational. Your controls are working correctly on the traffic they were pointed at. The traffic that matters is not passing through them, which is a different problem from a control that is misconfigured.

Browser extensions are the quiet half

The 2026 report found that the average company has more than 15% of users running unauthorised AI browser extensions. Those extensions collect and retain browsing context from internal sites, which puts them outside the reach of conventional data loss tooling entirely.

This is worse than a chat window and gets a fraction of the attention. A chat paste is a deliberate act with a visible boundary. An extension with read access to every tab collects continuously, including from your admin consoles and your ticketing system.

Extension inventory is also the cheapest thing on this list to obtain. If you manage the browser, you can list every installed extension across the fleet this afternoon.

What changes the moment the account is personal

The model behind a personal ChatGPT session and an enterprise one is usually the same model. Everything wrapped around it is different, and the wrapper is what your obligations attach to.

The share of use running through personal accounts also varies enormously by tool, which decides the order you should provision in.

Training and retention defaults move with the plan

Consumer tiers may use conversation content to improve models unless the user opts out. Business and enterprise tiers exclude customer content from training by default, and add administrator controls, single sign-on, configurable retention and audit logs.

Note what the enterprise tier does not give you. Content is still transmitted, processed and stored for a period, because abuse monitoring requires it. Not trained on is not the same as not stored, and a vendor claim of zero retention deserves the reading discipline you would apply to any other contract term. The clauses worth arguing over are set out in the guide to AI contract clauses a finance team should insist on.

Consumer logs are already in discovery

In January 2026 a federal judge in the Southern District of New York ordered OpenAI to produce 20 million de-identified consumer ChatGPT logs to news publishers in the consolidated copyright litigation. The sample was drawn from tens of billions of preserved conversations.

Read that as an availability fact rather than a scandal. Consumer conversation logs exist in volume, they are retained, and a court can direct where they go. Your company was not a party to that case and had no standing to object on behalf of an employee's paste.

An enterprise workspace does not make you immune to litigation. It does mean the retention window, the export path and the deletion authority sit with your administrators. That is the difference between managing an obligation and discovering one.

Plan terms are the vendors' published defaults and they change without much notice. Re-read them at renewal rather than trusting this table a year from now.

Controls that hold on a managed device

There are only three places to intervene: the network, the browser, and the account. Most programmes spend their budget on the first, which is the weakest of the three.

Workspace restriction is the control most teams have not heard of

Both major vendors support a header that filters which tenant a user can sign into. OpenAI documents a ChatGPT-Allowed-Workspace-Id header carrying one or more workspace identifiers. Any workspace not listed, including a personal one, is filtered out at sign-in.

Google's equivalent is the X-GoogApps-Allowed-Domains header, which accepts a consumer_accounts value to exclude personal Gmail sign-ins. Both need something in the path to inject the header, which means an inspecting proxy with a trusted root certificate, or browser policy.

This is the only control on the list that separates the tool from the account. Everything else forces a choice between allowing the tool for everyone and denying it to everyone.

The managed browser is the real control plane

Browser policy travels with the device. A network rule stops applying the moment a laptop is on a home connection, and that is where a large share of this activity happens.

If you buy one thing this quarter, buy browser management before you buy another network appliance. It gives you extension inventory, sign-in restriction, paste-event visibility and policy that survives off the corporate network. No proxy delivers that set.

Be honest with yourself about the limit. None of this reaches a personal phone on a mobile network, and no control in this article ever will.

Three controls that keep failing

The first is the blanket block. It reads as decisive and it relocates the problem to hardware you do not manage, taking your last telemetry with it. Blocking a category that 45% of your staff use daily also tells them the security function is an obstacle, which is expensive in ways that never show up on a dashboard.

The second is the policy-only programme. A July 2026 survey of 500 employed US adults, run by Kolmogorov Law through the Pollfish panel, found 38% had entered work information into a personal AI account, and only 35.8% reported a clear written workplace AI policy. That survey is small and law-firm commissioned, so treat both figures as directional rather than settled.

The third is keyword-matched data loss prevention pointed at prompts. It was built to catch card numbers and national identifiers. Source code, internal architecture and unreleased pricing match none of those patterns, so the top uploaded category slips past a control that reports itself as green.

Where this argument is weakest

Three things in this post would not survive a hostile review, and you should know which they are before you cite them internally.

The denominator is monitored devices, not employees

Every figure here comes from telemetry collected on devices already running security agents, at organisations that buy those products. That population is more governed than the average firm, not less. The direction of the bias is genuinely unclear: it could understate the problem across the wider economy, or overstate it by sampling companies with heavy monitoring and heavy AI adoption together.

Vendor telemetry has a second issue. Cyberhaven, Harmonic and the data loss vendors feeding the breach report all sell products that address the risk they are measuring. That does not make the numbers wrong. It does mean nobody in the chain has an incentive to publish a small one.

The most useful independent check is a boring one. Harmonic's index classified 1.9 million AI session minutes over seven weeks to April 2026 and found 64.5% of activity on personal accounts was business use. Different vendor, different method, same conclusion, which is weak corroboration rather than proof.

The strongest counter-case is that this is a transition artefact. Enterprise provisioning lags adoption by roughly a year, and if provisioning catches up the personal account share falls without anyone deploying a control. If you believe that, the right move is to provision faster and spend less on enforcement, and I think that reading is defensible for a company under 200 people.

A 30 day sequence that produces evidence

Order matters more than completeness. Each step here produces something you can show a board, and none of it needs a procurement cycle to start.

Week one is inventory from data you already hold. DNS resolver logs give you the domains, your identity provider gives you the third-party grants, and the corporate card ledger gives you the paid consumer subscriptions. Those same three sources answer the wider question of tool sprawl covered in the analysis of 291-app estates and what rationalisation recovers.

Week two is the managed browser rollout and the extension audit that comes free with it. Week three is the workspace restriction header on a pilot group, because header injection breaks things and you want to find that out on 30 people rather than 3,000.

Week four is the measurement nobody does. Compare the same DNS and card signals against week one and write down what moved. Spend visibility is the part most teams underrate, and the tooling options are compared in the review of AI spend forecasting tools.

Frequently asked questions

The first week, in three moves

Pull your DNS resolver logs for the last 30 days and count distinct AI domains resolved, then count the ones your policy names. The gap between those two numbers is your actual scope, and it usually surprises the person who wrote the policy.

Ask your identity provider for every third-party application grant issued in the last quarter. Sort by user count, not by risk score. The tools with the most users are the ones your enterprise workspace has to replace credibly.

Then pick one engineering team and ask them what they paste and why. Not to discipline anyone. To find out which part of your sanctioned path is slower than the unsanctioned one, because that gap is the whole programme.

Related reading