OpenAI Ships Lockdown Mode: What It Disables, and Who Should Turn It On

Summary

OpenAI has shipped an advanced security toggle called Lockdown Mode, rolling out across Free, Go, Plus, and Pro personal accounts plus self-serve ChatGPT Business accounts. What it does is concrete: it disables or sharply limits the capabilities in ChatGPT that can reach the network or external services, in order to block the final step of a prompt injection attack, the moment your sensitive data gets sent out to an attacker.

The thing worth pausing on is not the feature but the fact of it. OpenAI states in the docs that the mode “is not intended for everyone,” but for people and organizations that handle sensitive data and want stricter protection against exfiltration. Translated: the default ChatGPT config is not safe enough for journalists, dissidents, and rights lawyers, who need an extra wall. That is an admission that the safety boundary of an AI product has moved beyond “will the model say something wrong” to “what adversary is the user facing.” It is the signal of threat modeling arriving in a consumer AI product.

What happened

Lockdown Mode is an optional advanced security setting, turned on under Settings > Security > Advanced security. It is available for all account types and workspaces, as long as you are logged in. Once on, the following web- and external-service capabilities are disabled or limited:

Live web browsing is restricted to cached content, so search results may be limited, unavailable, or stale. Image support is limited: ChatGPT may not display images in regular responses or fetch images from the web, though you can still upload image files and image generation stays available where it otherwise is. Deep research is disabled. Agent mode is disabled. In Canvas, you cannot approve generated code to access the network. ChatGPT cannot download files for data analysis, though it can still operate on files you upload manually.

What it leaves untouched matters just as much: memory, file uploads, the ability to share a conversation, and whether your conversations may be used to improve models are all unchanged, and many of these are configured separately by workspace admins. It also does not affect network access in Codex.

For apps and connectors, the logic varies by account type. On personal and self-serve Business accounts, Lockdown Mode allows connectors that use synced data but blocks live connector access and connector write actions; experiences like Finances in ChatGPT and shopping-agent flows are unavailable. In managed workspaces, apps, MCPs, and connectors are governed by workspace settings and role-based access control (RBAC), and Lockdown Mode does not automatically disable every app, so admins must allow only the trusted apps and actions their members need. The docs add a risk tiering: read or write actions for untrusted apps, and write actions for trusted apps whose side effects might be visible to a malicious actor, are high risk and not recommended; sync connectors and read actions for trusted apps are medium risk and usable with caution, since they create no outbound request or write side effect, though they can still be a source of sensitive data an attacker tries to exfiltrate.

Why it matters

The design goal is stated with notable restraint: Lockdown Mode defends only the last link of a prompt injection. As the docs put it, it “does not prevent prompt injections from appearing in the content ChatGPT processes,” since an injection can hide in cached web content or an uploaded file and still affect a response’s behavior and accuracy. All it does is limit the outbound network requests that would carry your data out. That is an honest boundary statement, and it reveals OpenAI’s real read on the problem: prompt injection is a frontier, hard research problem that cannot be solved at the model layer soon, so the next-best move is a gate at the exit.

This pushes the meaning of “AI safety” hard toward the user side. AI safety has centered on model alignment: whether a model outputs harmful content or can be jailbroken. Lockdown Mode is about something else, the case where an attacker plants malicious instructions in the content you feed the model, and the model becomes a leak channel back out. That is classic threat modeling, with the object swapped from a corporate network to an assistant that browses, calls tools, and reads your files. Conceding that the default config is not safe enough for high-risk people means OpenAI is explicitly handing part of the safety responsibility back to users: you decide whether you are a high-risk target, then decide whether to pay the price of losing browsing, deep research, and agent mode.

Note a seemingly contradictory judgment in the same docs: prompt injection “is not currently a major risk, but its impact could grow as attackers develop more sophisticated methods.” Read together, Lockdown Mode looks more like a defensive position deployed ahead of the threat than an emergency response to a present danger. Handing users the control and the threat-modeling frame before the risk has materialized is itself a product posture worth recording.

Builder impact

If you build on top of ChatGPT, or ship to high-risk users, there are a few direct adjustments here.

First, do not sell Lockdown Mode to users as a privacy or compliance switch. It and data controls are two separate systems: training use, memory, and sharing are all outside its scope. The docs stress this repeatedly precisely because it is the easiest thing to misuse. To govern data use you go to data controls separately; managed workspaces also have the Compliance API logs platform for visibility into app usage, shared data, and connected sources, and Lockdown Mode does not change what it logs.

Second, if your product relies on ChatGPT’s browsing, deep research, agent mode, or connector write actions, assume some fraction of users are in Lockdown Mode and those capabilities are simply unavailable. Provide a graceful degradation path rather than letting features fail silently. Connectors especially: on personal accounts, live access and write actions are blocked and only synced data remains, so your integration has to stay useful on that minimal read-only-synced set.

Third, managed-workspace admins must make real trade-offs. The docs advise configuring by each app and action’s exfiltration risk: do not enable reads or writes for untrusted apps, and do not enable a trusted app’s write action if its side effect could be visible to a malicious actor. For high-risk members, the default should be a minimal trusted allowlist, not “enable everything and disable as needed.”

What to ignore

Do not read Lockdown Mode as “turn it on and you cannot be hit by prompt injection.” The docs are blunt: it substantially reduces the risk of injection-based exfiltration but does not guarantee exfiltration cannot happen, since risk can still leak through enabled apps, unforeseen capability combinations, or newly discovered techniques. More importantly, it does not prevent the injection itself: a malicious instruction in an uploaded file can still make ChatGPT answer wrong or behave off-track, the data just cannot get out. Treating it as a total shield is dangerous, because “I have Lockdown Mode on” tends to relax vigilance about the input content itself.

And do not read “prompt injection is not currently a major risk” as “so ignore it.” OpenAI’s full judgment is that the risk grows as attacker methods mature, and Lockdown Mode is deployed ahead of that judgment. For the vast majority of ordinary users, you genuinely do not need to disable half your features today. But if you, or the people you serve, are journalists, dissidents, or handle sensitive sources, the default config’s risk is real and this wall is built for you. Deciding whether you are on that line matters more than agonizing over whether to flip the switch.

Sources

1. Lockdown Mode (OpenAI Help Center) / official