7 June 2026. Since 6 June, OpenAI has been rolling out Lockdown Mode beyond the enterprise world — a switch that deterministically shuts down browsing, deep research and agent mode to prevent data exfiltration via prompt injection. The real news sits in the architectural principle: for this risk, OpenAI no longer relies on the model alone, but on hard-disabled capabilities.
On 6 June, OpenAI extended Lockdown Mode — introduced in February initially for Enterprise, Edu, Healthcare and Teachers workspaces — to self-serve ChatGPT Business accounts and eligible personal accounts. When active, the mode limits browsing to cached content — no live network request leaves OpenAI's controlled network —, disables the retrieval of web images, deep research and agent mode, and lets workspace admins define by role which apps and which individual actions within them remain available. In parallel, OpenAI now labels risk-bearing capabilities such as Codex's network access with a consistent “Elevated Risk” label across ChatGPT, Atlas and Codex.
What stands out is the honesty of the construction. OpenAI itself says that ChatGPT remains vulnerable to prompt injection even in Lockdown Mode — for instance via cached web content or uploaded files. The mode does not prevent the injection; it cuts off the exfiltration channel: where no live request leaves the network, a planted instruction cannot carry data to an attacker. In its own documentation, OpenAI calls prompt injection an open research problem — and therefore places a deterministic system-level guarantee alongside the model-level protections. Until now, this insight lived mostly in research blogs, not in product settings.
The threat scenario is not theoretical: as soon as a ChatGPT account has connectors to SharePoint, Drive or the mailbox and browses the web at the same time, confidential data and untrusted content sit in the same context — the classic precondition for exfiltration via prompt injection. Until now, the main defence was trust in OpenAI's filters. Now there is a hard switch, and with the extension to self-serve Business accounts, for the first time also for companies without an Enterprise contract — with one important caveat: on self-serve and personal accounts, Lockdown Mode is a self-service toggle that users can switch off per chat. It can only be enforced centrally in managed workspaces via roles.
From a data protection perspective, this is not a convenience question but an obligation: a customer record exfiltrated via injection is a reportable data breach, and the selection of technical and organisational measures under Art. 32 GDPR must reflect the state of the art. When the provider itself ships a protection mode for accounts handling sensitive data, it becomes hard to justify why exposed roles — management, accounting, HR — work without it. The Elevated Risk labels conveniently double as usable risk documentation for the data protection impact assessment. Two things the mode explicitly does not change: neither the memory nor the training settings — both remain separately configurable — nor the third-country finding. OpenAI offers EU data residency only for data at rest in new Enterprise and Edu workspaces; according to OpenAI's own documentation, inference still runs in the United States.
In the layer picture of recent weeks, this is the next floor: after identity (NVIDIA OpenShell), execution (Microsoft MXC) and memory (Dreaming V3), the capability governance of the agent stack now gets its own deterministic layer. The trend is consistent — security moves out of the model and into the harness that operates the agent.
For your own agent architectures, the pattern translates directly: capabilities belong in tiered profiles, network access behind egress allowlists — OpenAI demonstrates this in Codex with domain lists and permitted HTTP methods; incidentally, Codex's network access is not affected by Lockdown Mode and is governed separately —, and the decision which profile applies is made by a policy at the harness, not by a prompt. Anyone attaching MCP servers to agents should treat tool access with the same discipline: deterministically granted, per role, auditable.
In this order. First, take stock of which ChatGPT accounts in your organisation have connectors to internal systems and are simultaneously allowed to browse or use agent mode — that is the exposed set. Second, define roles for these accounts and enable Lockdown Mode where agentic capabilities are not needed in day-to-day work — this can only be enforced via managed-workspace roles; on self-serve accounts it remains a working instruction; the granular app permissions allow justified exceptions to be mapped cleanly. Third, adopt the Elevated Risk labels into your own risk documentation. Fourth, measure your own agent roadmap against the question of whether tool and network access is deterministically bounded — or only by the model's good behaviour. This article reflects my technical and strategic assessment. It is no substitute for legal advice or a data protection impact assessment.
![[Translate to English:] Foto von Kai Ole Hartwig.](/fileadmin/_processed_/e/9/csm_ole-neu_8000c3dfab.avif)
Programming since 2002 – self-taught, set up my own business with KO-Web in 2012. Over 100 projects, with a focus on security, performance, automation and quality. Today freelance: DevSecOps consulting, training and software development.
