14 Oct 2026 · Constance Ibe-Whitmore (editorial persona) · Governance and leadership · on threat.cafe

Two-thirds of AI users at work use personal accounts: moving coding agents to managed tenancy without a ban

The 2026 Verizon Data Breach Investigations Report, as summarised by the Cyber Readiness Institute, finds that 67% of users access AI services through non-corporate accounts on work devices. For chat tools, that is a data-handling problem. For coding agents, which run shell commands, install packages and connect to tool servers, it also means the organisation's policy never reaches the process doing the work. A ban without a sanctioned alternative leaves the personal path as the only one. The defensible sequence is to make the managed path cheaper and faster for developers than their personal one, then enforce it at the device, where agent policy can be pinned to the organisation's login.

Executive summary of the finding

Two figures frame the problem. Verizon's 19 May 2026 release says frequent use of AI tools by employees rose "from 15% to 45% of employees in a single year," and that shadow AI is "now the third most common non-malicious data leakage related activity." CRI's summary adds the 67% non-corporate figure.

Neither figure isolates coding agents. The inference here is narrow. If two-thirds of AI users at work are on personal accounts, the developers among them are unlikely to be the exception, and a coding agent on a personal plan carries tool access that a chat window does not.

Status of the evidence

The 45% figure comes from Verizon's own release. The 67% figure comes from CRI's secondary summary, published 1 June 2026, and was not checked against the full DBIR for this article. Policy built on it should cite it as "DBIR 2026, as summarised by CRI" until the full report is consulted. The 45% measures frequent use. Other surveys measure any use of unapproved tools and report higher shares, so definitions should be stated whenever figures are compared.

Scope: which agent sessions an organisation's policy actually reaches

Using Claude Code as the worked example, the managed settings documentation describes two delivery halves, and the distinction is the centre of this article.

Device policy follows the machine. A managed-settings.json file in the system directory, or an MDM profile, applies to sessions on that device. The paths are /Library/Application Support/ClaudeCode/ on macOS, /etc/claude-code/ on Linux and WSL, and C:\Program Files\ClaudeCode\ on Windows. Per the settings precedence documentation, managed settings sit above command-line, project and user settings, and nothing in a developer's own files overrides a managed key.

Account policy follows the login. Server-managed settings, set in the claude.ai admin console, are fetched "only when the session authenticates to Anthropic's API directly with an eligible credential." A session signed in with a personal subscription is not the organisation's credential, so it does not receive the organisation's console policy.

The two halves meet in one setting. forceLoginOrgUUID is documented to "Pin claude.ai logins to your organization; only a managed source enforces it." Delivered as device policy, it closes the personal-account path on managed machines.

Exclusions matter too. The same documentation says cloud sessions do not read a device's file or MDM profile, and that Cowork sessions in the Claude Desktop app never fetch server-managed settings even with a Team or Enterprise login. Each surface your developers use needs its own check.

Managed versus personal: what the organisation gets

The table separates the login from the machine, because the two halves of policy follow different things.

Capability                     Org login,          Personal login,      Personal login,
                               managed device      managed device       personal device
-----------------------------  ------------------  -------------------  ----------------
Device policy (file or MDM):   Yes                 Yes                  No
permission rules, hooks, MCP
allowlist, sandbox locks
Console (server-managed)       Yes                 No                   No
policy
Policy for cloud sessions      Console policy      No                   No
Offboarding by removing the    Yes (inference)     No                   No
org seat
Login pinned to the org        forceLoginOrgUUID   Blocked once the     Not reachable
                                                   pin is deployed

Device policy carries the controls with the most security weight: permission rules that sit above user settings, allowManagedHooksOnly to run only the organisation's hooks, allowedMcpServers with allowManagedMcpServersOnly for an MCP allowlist, and sandbox locks. A personal login on a managed device still gets those. What it escapes is console policy, cloud-session policy and seat-based offboarding, and the pin closes that gap. Setting names are taken from Claude Code's documentation as of October 2026. Other agents use different names for equivalent controls, and some lack them.

Obligations: must, should, may

This matrix uses "must" for controls without which the managed path does not exist, "should" for controls that make it hold under pressure, and "may" for discretionary measures.

Must

The organisation must provide a sanctioned agent seat for every developer who uses agents for work. A policy that forbids personal accounts without offering a managed one produces the 67%.
Device policy must be deployed to managed developer machines through managed-settings.json or MDM, since console policy alone does not reach personal logins.
On machines where agent use is approved, device policy must pin the login to the organisation with forceLoginOrgUUID.

Should

The managed seat should match or beat the personal plan on the things developers notice: model access, usage limits and setup time. Developers move to the managed path when it is the faster one.
Device policy should restrict MCP servers to an allowlist and run organisation hooks that log tool calls, so incidents can be reconstructed.
Every surface in use (terminal, IDE extension, desktop app, cloud sessions) should be checked against the documentation's coverage list. Cloud sessions need console policy, not device policy.

May

The organisation may grant a time-boxed amnesty: developers declare personal-account agent use without penalty and are migrated within a set window.
The organisation may reimburse personal plans during migration rather than cut them off on day one.
The organisation may detect agent processes on managed devices through endpoint inventory and compare that list with sanctioned seats.

Sequencing and verification

Week 1: measure. Inventory agent processes on managed devices and compare with sanctioned seats. The gap is your personal-account population.
Weeks 2 to 4: offer. Provision seats and announce the amnesty. Publish what the managed path gives developers, not only what it restricts.
Week 5: deploy device policy in audit posture first: hooks that log, MCP allowlist populated from the inventory.
Week 6 onward: pin the login. Turn on forceLoginOrgUUID for approved machines.

Verify each step by opening a session on a test machine with a personal login and confirming that it cannot sign in once the pin is active.

What developers give up, and how to offset it

A migration plan that ignores what developers lose on the managed path will stall at the amnesty stage. The likely objections, and the offsets an organisation controls:

Their own skills, hooks and MCP servers. Under an MCP allowlist and allowManagedHooksOnly, personal additions stop loading. Offset this with a published request process and a turnaround target measured in days, and seed the allowlist from the week-1 inventory so existing workflows keep working.
Model access and usage limits. If the sanctioned seat is a lower tier than the personal plan, developers will notice on the first day. Match it, or explain the gap plainly.
Speed of setup. A managed seat that takes two weeks to provision loses to a personal sign-up that takes two minutes. Provision before announcing.
Privacy of their own experiments. Be explicit about what organisation hooks log and who can read it.

Each of these is a design choice inside the organisation's control. None needs a vendor change.

Questions for internal counsel and HR

Does monitoring agent processes on company devices fall within existing acceptable-use and monitoring notices in each jurisdiction where developers work?
Who owns code and prompts produced under a personal subscription before migration, under that vendor's consumer terms?
Does the amnesty need to be written into policy to be relied upon?

This is general information, not legal advice. Monitoring and ownership questions turn on local employment law and the vendor's current terms, so take them to your own counsel.

Ambiguities and open points

The 67% figure awaits confirmation against the full DBIR. Its population is AI users on work devices, and it does not separate developers. Personal machines, which device policy cannot reach, remain outside this design altogether. The honest position for a policy document is that managed tenancy governs managed devices and organisation logins, and that personal hardware needs a separate decision.

Once agents run under organisation policy, a shared known-bad check becomes deployable in one place; the threat.cafe early-access list is open to teams planning that rollout.

Sources

#shadow-ai #managed-settings #coding-agents #governance #claude-code

All posts