ChatGPT for Work: Enterprise Agents Are the New Shadow IT

OpenAI's ChatGPT for Work is the clearest sign yet that the assistant in the browser tab has become an agent with hands. Built on the compliance foundation of ChatGPT Enterprise, it adds agentic capabilities: it can produce documents, spreadsheets, and presentations, write and run code, and connect to the systems your business already runs on. Through connectors to platforms like Microsoft 365, Google Drive, Slack, and Notion, it turns ChatGPT into a retrieval-augmented agent that reads across SharePoint, Salesforce, Drive, and the rest of your internal data.

That is a genuinely useful product, and OpenAI has paired it with real governance controls. It is also the cleanest expression of a problem we have been describing since day one: AI agents are the new shadow IT. The sanctioned workspace is the part you can see. The sprawl around it is the part you cannot.

What ChatGPT for Work actually does

It helps to be precise about the capability, because the security conversation only makes sense once you see how far the product reaches. Workspace agents in ChatGPT for Work can access company files, Slack channels, email, and CRM records; they can respond to messages, write code, and - the property that matters most - run in the cloud unattended so work continues without a human watching. That combination, autonomous execution over connected enterprise data, is what moves this from a chat box to an actor inside your data estate.

If the category itself is new to your organization, our complete guide to shadow AI sets the baseline. The short version: the moment an assistant can read your systems and act on them, it stops being a productivity tool and becomes something you have to govern like any other privileged actor.

OpenAI's admin controls are real, and they stop at the workspace edge

Give OpenAI credit here, because the admin surface is substantive. Administrators can control which users are allowed to launch agents. They can configure, on a per-agent basis, which connected tools are in scope for that agent. They get real-time monitoring of activity, OpenAI runs automated red-team evaluations against the agents, and data is encrypted with AES-256 at rest and TLS 1.2 or higher in transit. For a sanctioned, centrally provisioned deployment, that is a reasonable baseline and worth turning on.

The limit is structural, not a knock on the controls. Every one of those governance features operates inside the boundary of the workspace OpenAI manages for you. They govern the agents you launched through the console you were given. They say nothing about the AI activity happening on the same laptops, under personal logins, through browser extensions, or via local tooling that never touched that console. A vendor can only govern what runs inside its own product. Your risk does not respect that boundary.

The blind spot is the sprawl

The real exposure is rarely the workspace you carefully configured. It is everything adjacent to it: an employee signing into a personal ChatGPT account to get around a rate limit or a blocked connector, a browser extension that quietly pipes page content to a model, the ChatGPT desktop app installed outside IT, command-line tools, and local MCP servers and connectors that a developer wired up to reach the same sensitive data. None of that appears in the admin console, because none of it is the sanctioned workspace.

We have measured what this looks like in practice. What employees actually paste into ChatGPT shows that the majority of generative-AI data movement flows through unmanaged personal accounts sitting entirely outside enterprise SSO and DLP. And the behavior is not evenly spread: shadow AI adoption varies sharply by department, which means any single admin console gives you one partial slice of a pattern that is fleet-wide.

A per-vendor console is not a fleet inventory

Here is the trap. The ChatGPT for Work admin console is excellent at governing ChatGPT for Work. But your fleet does not run one vendor. The same engineers using ChatGPT are also running Claude Code, GitHub Copilot, Cursor, and a rotating set of MCP servers. Each vendor ships its own console, its own policy model, and its own blind spots. Ten consoles is not visibility. It is ten partial views that nobody reconciles into a single picture.

The one thing every item in that right-hand column has in common is the endpoint. The desktop app, the extension, the CLI, the local MCP connector - they all live on a managed machine. That is why the durable inventory has to be built there, not inside any one vendor's cloud. How to build an AI agent inventory walks through that foundation, and the permissions agents actually request shows why the gap between what an agent was granted and what it truly needs is the thing you most want to see once discovery is in place.

Why network and DLP tools do not close the gap

The instinct is to point the controls you already own at the problem. But ChatGPT for Work is largely a SaaS and browser product talking to cloud connectors, and that is exactly the shape legacy tooling was not built to see. Traditional DLP fails for AI agents for the same architectural reason it misses a clipboard paste into a web text box: the sensitive event leaves no managed file artifact and never crosses a sanctioned API. Network and EDR tools see traffic and processes, but they do not enumerate which AI agents, MCP servers, extensions, and connectors are present on a machine and what each one is allowed to touch. Visibility has to come first, at the layer where these artifacts actually live.

A vendor console governs the agents you launched inside it. It cannot govern the ones you never told it about. That is the difference between a product setting and a fleet inventory.

How Anomity governs the ChatGPT for Work blind spot

Anomity sits above any single vendor's console. Our unprivileged Endpoint Sensor runs on Windows, macOS, and Linux and inventories eight AI artifact types across every managed machine: AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs (see the full feature set). In the ChatGPT context that means the sensor discovers the ChatGPT desktop app, browser extensions, CLIs, and any local MCP servers or connectors as artifacts on the endpoint. To be precise about scope: Anomity does not intercept OpenAI's cloud-side connector traffic. It gives you the fleet-wide inventory of the AI footprint on your machines that no vendor console can, and it complements your existing Network, EDR, DLP, and GRC stack rather than replacing it.

On top of discovery, Anomity adds runtime governance wherever an agent exposes a hook. At a Claude Code PreToolUse hook, for example, Anomity can allow, deny, or log a call before it runs. Everything it collects is metadata-only, with secret redaction performed on the endpoint, and it lands in a queryable 90-day audit trail that routes to your SIEM, Slack, email, or Jira. The platform is SOC 2 Type II. See inside Anomity discovery for how the sensor builds the picture and the docs for the artifact model, and where agentic visibility is heading in 2026 for why this stops being optional.

OpenAI's admin controls are worth turning on. They are just not the whole picture, because a per-vendor console can only ever govern one vendor. You can't govern what you can't see. If you want a fleet-wide view of every AI agent, MCP, and connector on your endpoints - across ChatGPT for Work and everything running beside it - request early access.