International access: https://4sapi.com
Domestic access: https://4sapi.org
Abstract
On October 20, OpenAI rolled out Locked Chats, a new privacy-focused feature for ChatGPT. This functionality lets users protect selected conversations behind a 4-digit account PIN, with biometric authentication options such as Face ID and Touch ID available on mobile devices. Locked conversations are hidden from standard chat history, pinned lists and global search results, and isolated inside a dedicated section labeled Projects > Locked Chats. After identity verification, users can resume working on these protected sessions normally. The feature is being released in phased rollout, covering Free, Plus, Pro, Business, Enterprise and Edu subscription tiers, and it supports web, iOS, Android and the newly launched desktop client.
It is critical to define the feature’s proper scope. Locked Chats operates more like a screen privacy filter. It addresses scenarios where a third party might glance at sensitive content during screen casting or when a user temporarily lends their device to another person. It does not implement end-to-end encryption, create separate encrypted storage vaults, alter default chat retention policies, automatically disable model training opt-in settings, or erase existing persistent memories that the assistant has already stored. Many users may misinterpret this feature as a strong data security boundary, so this article breaks down its authentication flow, isolation rules, hard operational limits, unsupported chat types, and the complementary controls users must configure separately to meet strict privacy requirements. It also discusses the broader implications for API and enterprise workflow security, and clarifies where this feature fits into a complete data governance stack.
1. Core Functional Overview of Locked Chats
Locked Chats introduces an access control boundary at the conversation UI layer. When a user enables locking for a specific chat thread, several visibility changes take place immediately. The thread disappears from the regular chat history feed, pinned conversation group and the application’s built-in search index. It can only be accessed from the dedicated Locked Chats subsection under the Projects menu. This isolation ensures that anyone navigating the ChatGPT interface without completing authentication cannot discover or open these protected conversations through normal browsing or keyword search.
The primary authentication credential is a four-digit PIN bound to the user’s account. Mobile platforms add supplementary local biometric verification pathways. Face ID and Touch ID act as convenient alternatives to PIN entry; these biometric checks run on the local device and serve only to unlock the protected chat view. Biometric data itself is not sent to OpenAI’s servers for the purpose of this chat lock.
The rollout plan spans the full spectrum of ChatGPT subscription plans. No major tier is excluded from the feature. Free tier users, Plus subscribers, Pro power users, Business accounts, Enterprise organizations and educational Edu accounts are all included in the release schedule. Client-side coverage is equally broad: the web interface, native iOS application, Android application, and the new desktop ChatGPT client all receive the capability as the phased deployment progresses. This wide footprint signals that OpenAI intends this as a general-purpose user-facing privacy tool, rather than an enterprise-only administrative control.
A common misconception to address upfront is the difference between UI hiding and cryptographic protection. Hiding a chat from search and history is an application-layer visibility rule. It restricts what an onlooker can see on the active screen, but it does not rework how OpenAI stores, processes or retains the underlying chat payload on backend servers. This distinction underpins every operational boundary of Locked Chats.
2. Feature Positioning: Privacy Screen, Not Secure Vault
OpenAI’s own framing places Locked Chats firmly in the category of shoulder-surfing protection. The use cases it is designed for are very specific: sharing a screen during a presentation, handing a phone or laptop to a friend or colleague, or leaving an unlocked device unattended briefly in a shared space. In these situations, the main risk is visual exposure of sensitive text to someone physically present, not remote data exfiltration or server-side compromise.
Three major security guarantees that users might reasonably expect are explicitly not provided by Locked Chats.
First, there is no end-to-end encryption (E2EE) applied to the conversation content. The chat payloads still travel to OpenAI’s cloud infrastructure and are processed by the model service following standard platform policies. End-to-end encryption would mean that only the endpoints hold decryption keys, and the service provider cannot read plaintext content. Locked Chats does not implement this cryptographic model.
Second, it does not provision an independent encrypted storage vault. Protected chats are stored within the same backend data system as unprotected conversations. The only difference is the access flag that controls whether the thread appears in standard UI views. There is no separate, isolated encrypted partition for locked content.
Third, it does not modify retention lifecycle rules. Enabling the lock does not shorten or extend the default retention window for chat records. The data expiration policy that applies to regular chats continues to apply unchanged to locked chats.
Two additional automatic safeguards that many users may assume exist are also absent. Locking a conversation does not toggle the “improve model using this data” training consent setting. If a user has opted their conversations into model training, locked chat content remains eligible for training unless the user manually adjusts the data control setting elsewhere in account configuration. The lock also does not scrub persistent memories already captured by ChatGPT’s memory feature. Any facts, preferences or context the assistant has already stored from prior interactions will persist even after the chat thread is locked.
This positioning means Locked Chats solves a narrow user experience problem. It reduces incidental visual leaks. It is not a compliance control for regulated data such as health records, financial identifiers or confidential corporate intellectual property. Organizations handling regulated data must continue to rely on Enterprise administrative controls, data loss prevention pipelines and separate encryption workflows.
3. Non-Negotiable Operational Boundaries and Edge Cases
OpenAI has documented three critical hard limits that carry irreversible consequences for users, and these are often overlooked in high-level summaries of the release. These boundaries define where user responsibility begins, beyond the simple PIN unlock flow.
3.1 PIN Reset is a destructive, irreversible action
Simply forgetting the PIN does not delete chat content. The records remain intact on the backend; the user is merely blocked from viewing them through the Locked Chats interface until they can authenticate correctly. However, the explicit “Reset PIN” operation is destructive. When a user triggers PIN reset, every locked conversation, all memory entries confined exclusively to the locked chat scope, and protected attached files associated with locked threads are permanently erased. This deletion cannot be recovered. OpenAI support staff and enterprise administrators have no ability to restore content removed by a PIN reset. This creates a sharp operational risk. Users who reset their PIN for troubleshooting or security reasons must accept full data loss for all locked artifacts.
3.2 Existing share links remain functional after locking
Conversation locking only controls visibility within the authenticated ChatGPT application UI. It has no effect on public or shared chat URLs that the user previously generated. If a user sent out a shareable link to a conversation before applying the lock, that link continues to work for anyone who possesses it. Locking the thread later will not revoke access via the existing share link. Users must manually locate and delete each shared link separately if they need to revoke external access. This is an important separation of concerns: UI access control and external share-link revocation operate independently.
3.3 Memory segmentation rules are limited
The memory system follows a “old records persist, new locked sessions are segmented” model. Locking a chat does not retroactively strip memory that ChatGPT already captured. The memory associated with the locked thread is only isolated for new content within the locked scope. Existing memories collected before the lock was applied remain active across the rest of the user’s ChatGPT sessions. If a user wants to fully prevent content from being used for model training, memory retention and training opt-outs must be managed from the dedicated Data Controls page in account settings. The chat lock cannot substitute for these global account-level toggles.
4. Chat Types That Cannot Be Locked
Locked Chats support is selective. Several common ChatGPT session types are excluded from the locking function entirely. Unsupported categories include temporary chats, group conversations, scheduled task threads, meeting transcription recordings, and the dedicated medical version of ChatGPT.
This exclusion list reinforces the feature’s narrow purpose. Temporary chats are already designed to avoid long-term persistence, so an extra UI lock layer is redundant for their intended lifecycle. Group chats have multiple participants with separate permissions and sharing flows, which complicates the simple single-user PIN authentication model that Locked Chats uses. Meeting recordings and medical chat threads carry higher compliance burdens; OpenAI is avoiding the risk of users treating this lightweight screen lock as sufficient protection for highly regulated datasets.
5. Broader Context: Where Locked Chats Fits in a Complete Security Workflow
For individual users, Locked Chats is a useful first line of defense against casual visual snooping. For engineering teams and enterprises building workflows on top of OpenAI services, it is important to separate this client-side UI feature from API-layer security controls. The ChatGPT web and desktop application is a consumption surface, while programmatic access through the OpenAI API follows a completely separate authentication and data governance model.
Many teams running multi-model AI stacks combine OpenAI endpoints with other model providers. They need centralized access auditing, token quota enforcement and credential rotation across multiple LLM vendors. An API gateway can standardize authentication and logging across heterogeneous model services. 4sapi, functioning as an API gateway, delivers this unified routing and observability layer for teams operating distributed AI inference workloads. This type of gateway control addresses backend API access risks, a category of threat that the client-side Locked Chats feature is not built to mitigate.
The two categories of controls complement, rather than replace, one another. Locked Chats protects a user’s screen from passersby during interactive ChatGPT sessions. API gateway controls protect programmatic access, audit logs, rate limits and secret management for automated agent pipelines and backend integrations. Neither feature covers the full end-to-end security scope on its own.
Enterprises should build a layered model. First, use platform-native enterprise controls such as SSO, domain restrictions and admin data policies. Second, apply gateway-level routing, logging and credential management for API workloads. Third, guide end users toward Locked Chats for local shoulder-surfing risks, while clearly communicating its limitations. Finally, enforce separate data classification rules so regulated data never enters ChatGPT threads at all, regardless of locking status.
6. Practical Guidance for Users and Administrators
Based on the feature boundaries laid out above, there is a clear set of operational best practices.
For individual users:
- Treat Locked Chats only for low-to-medium sensitivity content where the main risk is visual exposure. Do not use it for regulated personal data, legal privileged content or critical trade secrets.
- Keep track of active share links before locking chats, and delete links when external access is no longer required.
- Avoid using PIN reset as a routine troubleshooting step, because it deletes all locked content irreversibly.
- Visit the Data Controls panel separately to adjust model training consent and manage persistent memory, because locking a chat will not alter these settings automatically.
- Recognize that temporary chats, group chats and medical ChatGPT sessions cannot be locked, and plan data handling accordingly for those workflows.
For enterprise administrators:
- Document the limitations of Locked Chats for internal security awareness training. Prevent staff from misclassifying it as end-to-end encrypted storage.
- Build separate controls for API usage, independent of the ChatGPT application’s client-side privacy features.
- Maintain data classification rules that block high-risk regulated data from being submitted to ChatGPT, regardless of whether users enable chat locking.
- Implement audit review workflows for shared chat links, because locking a conversation does not revoke previously distributed URLs.
7. Conclusion
OpenAI’s Locked Chats is a carefully scoped privacy feature that solves the specific problem of shoulder surfing and accidental on-screen exposure during device sharing or screen casting. It hides selected conversations from standard history feeds and search, secured behind a 4-digit PIN with optional local biometric unlock on mobile devices. The rollout covers all major subscription tiers and most official ChatGPT clients.
Its core limitation cannot be overstated. Locked Chats is a visibility control, not a cryptographic security boundary. It does not enable end-to-end encryption, create separate encrypted vaults, change retention rules, disable model training automatically or erase pre-existing memories. The irreversible PIN reset behavior, persistent share links and selective exclusion of temporary, group and medical chat types are all critical operational boundaries users must understand before adoption.
The takeaway can be summarized concisely: Locked Chats is a privacy drawer that keeps casual onlookers from reading your screen. It is not an impenetrable safe that protects data from the platform itself or downstream model training pipelines. To build robust AI data security, teams must combine client-side visibility controls, account-level data opt-outs, enterprise administrative policies, and centralized API access governance.
