ChatGPT Work's Local File and Code Execution: Enterprise AI Governance and Defense Guide

OpenAI's ChatGPT Work is quietly becoming one of the most consequential enterprise attack-surface expansions of 2026. What looks like a productivity feature is actually two distinct products — a cloud agent and a desktop agent that can access local files and execute programs on employee machines. Security teams that treat this as "just another chatbot" are going to learn the hard way that they've deployed an autonomous code-execution capability directly onto their endpoints, outside of traditional software inventory and change control.

This is not a vulnerability disclosure. There is no CVE here. But as practitioners, we don't wait for a CVE to govern a capability that reads corporate documents, executes arbitrary code locally, and is one prompt injection away from becoming a data exfiltration channel. This post breaks down what ChatGPT Work actually is, what the real risk model looks like, and the concrete governance and containment steps your organization should take now.

What Actually Happened

OpenAI announced ChatGPT Work on July 9, 2026, and has been iterating aggressively since. The critical detail that most organizations have missed — and that practitioners like Simon Willison have now documented — is that ChatGPT Work is two products sharing one name:

Work Cloud — accessed via chatgpt.com or the ChatGPT mobile apps. This is a cloud-hosted agentic environment. Your prompts, files, and agent activity live on OpenAI's infrastructure. The risk profile here is primarily about data residency, retention, and what corporate information employees are uploading into a third-party SaaS.
Work Local (the desktop app) — the desktop application (formerly branded Codex) grants ChatGPT Work the ability to access files and run programs directly on the user's computer. This is a fundamentally different security posture. We now have an LLM-driven agent with local filesystem read access and a local execution primitive, operating with the logged-in user's privileges.

That second product is the one that should keep a CISO up at night.

Technical Analysis: The Defender's Threat Model

Affected Products and Platforms

ChatGPT desktop application (Windows and macOS), formerly Codex — provides local file access and local program execution.
ChatGPT Work Cloud — web and mobile, cloud-side agent execution.
Any enterprise workstation where an employee has self-installed the desktop app, which in most environments is happening right now without IT approval.

Why This Matters: The Agentic Risk Triangle

There is a well-established principle in LLM security (often called the "lethal trifecta"): an AI agent becomes dangerous when it simultaneously has (1) access to private data, (2) exposure to untrusted content, and (3) the ability to take actions or communicate externally. The ChatGPT Work desktop agent satisfies all three by design:

Private data access: It can read local files — documents, source code, SSH keys, browser credential stores, .env files, anything the user can read.
Untrusted content ingestion: The agent processes content from web pages, emails, documents, and repositories. Any of that content can carry prompt injection payloads.
Action capability: It can run programs. It can also send data out through OpenAI's cloud plane.

The Attack Chain (Defender's View)

A realistic exploitation path against a Work Local deployment looks like this:

Delivery: An attacker plants a prompt injection payload in content the employee will ask the agent to process — a poisoned web page, a malicious README in a repo, a crafted PDF, an email summarization request.
Injection: The employee asks ChatGPT Work to summarize, review, or work with that content. The injected instructions hijack the agent's task.
Execution: The agent uses its local program-execution capability to read sensitive files (e.g., ~/.ssh/id_rsa, cloud CLI credential caches, browser cookies) and stage them.
Exfiltration: The agent transmits the data — via a network call it is instructed to make, by encoding it into an outbound request to an attacker-controlled domain, or by writing it into content synced through the cloud plane.

No malware binary ever touches disk. There is no exploit of a software flaw. The "exploit" is the intended functionality of the product, steered by adversarial text. Traditional AV/EDR signatures are largely blind to this because the executing process is a legitimate, signed OpenAI binary.

Exploitation Status

No CVE is associated with this story — this is a capability-risk issue, not a patched-flaw issue.
Prompt injection against agentic AI tools is actively demonstrated and observed in 2025–2026 across the industry, including against coding agents and browser agents. Treat exploitation of this class as practical and ongoing, not theoretical.
No CISA KEV entry applies; there is nothing to "patch." Mitigation is governance and configuration, not a vendor hotfix.

Executive Takeaways

Because this is a product-capability risk rather than a discrete vulnerability, the right response is organizational. Here is what we recommend to clients, in priority order:

Inventory before you govern. You cannot manage what you haven't found. Query your software inventory, EDR application telemetry, and proxy/DNS logs for the ChatGPT desktop app and OpenAI agent endpoints today. Assume shadow adoption — marketing, engineering, and finance teams are installing these tools faster than policy is written.
Publish an explicit two-track AI agent policy. Treat Work Cloud and Work Local as different risk classes, because they are. Cloud usage with sanctioned corporate accounts and defined data classification rules may be acceptable. Local file access and code execution should require explicit approval, an enterprise-managed workspace, and a documented business justification.
Contain the local execution surface. On managed endpoints, use application control (AppLocker/WDAC on Windows, Gatekeeper plus MDM restrictions on macOS) to block unauthorized AI desktop agents, or at minimum prevent them from launching child processes outside an approved allowlist. The highest-value control against agentic abuse is constraining what the agent can spawn.
Protect high-value local secrets from agent-readable paths. Move SSH keys, cloud credentials, and API tokens into hardware-backed stores or OS keychains rather than plaintext files in user profiles. Assume that anything readable by the user context is readable by the agent — and by extension, by a successful prompt injection.
Extend DLP and egress monitoring to the AI channel. Your data loss prevention program must treat LLM agents as an exfiltration vector. Monitor for unusual outbound data volume to OpenAI domains from workstations, alert on desktop agents reading credential-store paths, and log agent-initiated process execution with full command-line capture.
Train users on prompt injection, not just phishing. Employees understand malicious attachments; they do not yet understand that asking an AI agent to "summarize this vendor document" can silently turn the agent against them. Add agentic-AI scenarios to your security awareness program this quarter, and establish a norm that agents should never process untrusted external content while holding access to sensitive local data.

Remediation and Hardening Steps

There is no patch to deploy. Remediation here means configuration, control, and verification:

Enterprise licensing: Standardize on OpenAI's enterprise/team offerings where available, which provide administrative controls, audit logging, and data-processing terms that the consumer product does not. Verify the data retention and training-opt-out posture contractually.
Application control policy: On Windows, deploy WDAC or AppLocker rules that either block the ChatGPT desktop binary outright for unapproved users or constrain its child-process execution. On macOS, enforce via MDM (e.g., restricted software profiles).
Network controls: If your organization is not ready to sanction the product, block or alert on OpenAI agent/automation endpoints at the proxy and DNS layers, and monitor for the desktop app's update and telemetry channels as an adoption indicator.
Endpoint telemetry validation: Confirm your EDR captures process lineage under the desktop app (parent = ChatGPT desktop process, children = shells, interpreters, or scripts). Run a controlled test: have the agent execute a benign command and verify your SOC sees it with full command-line logging. If you can't see it, fix telemetry before approving the tool.
File-system access scoping: Where the product offers configurable directory permissions, restrict the agent to a dedicated working folder rather than broad home-directory access. Verify this configuration via MDM or scripted audit — don't trust user self-configuration.
Vendor tracking: OpenAI is iterating this product weekly. Assign someone to monitor OpenAI's release notes and security documentation for changes to the agent's permission model, and re-review your posture on each material update.

The Bottom Line

ChatGPT Work is a genuinely powerful product — and that is precisely the problem. A signed, legitimate, vendor-maintained binary that reads local files and executes local code under user context is a capability we used to call a RAT when malware authors built it. The difference is intent, and intent is exactly what prompt injection attacks. Defenders who get ahead of this now — with inventory, application control, secrets hygiene, and agent-aware monitoring — will avoid being the case study everyone else learns from in 2027.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub