Block Personal AI Accounts and Unapproved AI Apps

Ask any security leader where their company's code and data go when people use AI, and the honest answer is "mostly to our corporate workspace, and sometimes to someone's personal account". A developer signs in to an AI coding tool with a personal subscription because it was quicker; a contractor brings their own; someone installs an AI app the company never approved. Today we're shipping the controls to block personal AI accounts and unapproved AI apps, not just report them, on Windows, macOS and Linux.

Personal AI accounts are the leak you can't see

An approved AI app is only half the question. The other half is which account it is signed in with. The same app can send your source code to your company's workspace, where your contract, retention settings and admin controls apply, or to a personal account where none of them do.

Last month we started showing that difference: every AI app on your endpoints, the organization or workspace each one is signed in to, and Claude.ai and ChatGPT accounts used in the browser. You could mark each app and each account as allowed, flagged or disallowed. What you couldn't do yet was stop it. That is what changes today.

Block prompts from unapproved AI accounts

In Enforce mode, when a supported AI client is signed in to an organization you marked as unapproved, its prompts are blocked before they are sent, on any operating system. The person keeps their tool; they just can't use it with an account you don't control. Every event now carries the organization it came from, so you can see exactly which account each session ran under, and name your organizations once to see the names everywhere instead of IDs.

This is the control most teams ask for first. It doesn't ban AI; it moves AI use onto the accounts you already pay for and govern.

Stop unapproved AI apps on Windows, macOS and Linux

Some AI apps shouldn't run on company machines at all. With app blocking on, an AI app you disallowed is stopped on Windows, macOS and Linux, wherever that app can be stopped on that operating system. Where it can't, it is reported instead, and the console shows you where blocking applies across your fleet, so you are never guessing whether a policy actually takes effect.

The Enforcement page: what was blocked, and what would have been

Turning on blocking across a fleet is a decision you want to make with evidence. So both controls are off by default, and both run in two modes:

• Monitor records every case that would have been blocked, and blocks nothing.
• Enforce blocks, and records that it did.

The new Enforcement page brings it together: every policy, guardrail and app-block event, each marked blocked or would block, with the endpoint and user behind it.

The rollout that works:

1. See which AI apps and accounts are in use, and who uses them.
2. Decide: allow your corporate workspaces, disallow personal accounts and the apps you don't want.
3. Monitor for a while, and read the would-block rows. They tell you who would be affected and why, before anyone is.
4. Talk to the people behind them, then switch to Enforce.

By the time you enforce, nobody is surprised, and the Enforcement page shows the policy working.

Why this matters

Shadow AI isn't only the tool nobody approved. It is also the approved tool, signed in with the wrong account, and it is the hardest kind to see from the network. We built this at the endpoint because that is where the app runs, where the account is signed in, and where a prompt can be stopped before it leaves. It sits beside the posture score and risk worklist we shipped in June, in the same console.

More on how we approach it: shadow AI, and AI runtime security. If you are looking at a specific tool, see our pages for Claude and ChatGPT.

Try it

Find out how many personal AI accounts are signed in on your own machines. Start a free trial, and start in Monitor.