Check Point Research has documented a cross-account isolation failure in ChatGPT's code execution environment that could turn an ordinary conversation into a hidden task channel. In the researchers' proof of concept, a victim's session retrieved data from a connected Gmail account and relayed it to another ChatGPT account while the visible response appeared normal.
The finding was published on 8 September 2026 and is important for a precise reason: the model did not need direct internet access, stolen account credentials or a conventional container escape. Separate code execution containers could reach the same internal package service. Mutable metadata on that shared service was not isolated by account, so it could carry instructions and results between sessions.
The affected path is no longer available. Check Point says the channel had disappeared by the time its report was completed, and OpenAI confirmed that the identified internal Artifactory instance had been decommissioned. The publication does not establish widespread exploitation or identify affected customers. It describes controlled research performed in June and a concrete proof of concept.
How the hidden channel worked
ChatGPT created isolated containers for tasks that required code execution. According to Check Point, those containers could not directly communicate with each other or access the public internet. They could, however, use a shared internal JFrog Artifactory service to retrieve software packages.
The problem was not package retrieval itself. The service exposed operations that let a container attach properties to a repository item and read those properties later. The credentials available inside a container had enough permission to use both operations. Check Point wrote a test value from one account and retrieved the same value from a different account. Larger data could be divided across multiple properties and reassembled.
That behavior created what the researchers described as a shared clipboard. An attacker could place a hidden instruction into the channel. A malicious prompt, a shared conversation or a custom GPT could tell the victim's session to check for that instruction during a later turn. The visible request could still receive an ordinary answer while a second task ran with the victim session's available tools and permissions.
The Gmail demonstration showed why read access can be consequential. Check Point says the victim saw a small notice that Gmail had been used, but the notice appeared after the read and did not reveal the hidden request or returned data. The proof of concept therefore linked three boundaries that are often reviewed separately: tenant isolation, instruction trust and connected-app authorization.
What the evidence does and does not show
The primary evidence comes from the security researcher, not from a public OpenAI incident report. Independent reports from TechRadar and The Register corroborate the disclosed mechanism, the Gmail demonstration and the closure of the identified channel, but they rely on Check Point for the technical findings.
The research demonstrates that the path worked in the tested environment. It does not show that an attacker used it against customers in the wild. It also does not prove that every ChatGPT feature, account type or connected app was exposed. Impact depended on the tools, data and permissions available to the victim's session.
This distinction matters for incident handling. Teams should not treat every prior Gmail read or shared conversation as evidence of compromise. They should use the report to test whether their own agent platforms contain shared internal state, overbroad runtime credentials or read actions that lack an appropriate authorization boundary.
The control lesson is bigger than one shared service
Container isolation is only one layer of an agent security model. Every internal API, cache, package proxy, metadata store and management interface reachable from the runtime belongs inside the threat model. If one tenant can modify state that another tenant can read, the service can become a covert channel even when network isolation behaves as designed.
Connected apps expand the possible consequence. A runtime that can read email, source code, files or collaboration data should receive the minimum permissions required for the current task. Sensitive reads should be evaluated by data type, requester, purpose and destination, not classified as low risk solely because they do not change an external record.
Instruction provenance also matters. Text inherited from a shared conversation, custom agent configuration, retrieved document or external message should not automatically gain the same authority as the user's current request. The platform needs a way to separate trusted task instructions from untrusted content and to prevent hidden instructions from silently widening scope.
Teams can test these boundaries with the Maetra Secure sandbox and use the AI audit log guide to connect prompts, tool calls, data access and outcomes without collecting unnecessary content.
Questions for an enterprise review
Security and platform teams should inventory every shared service reachable from an agent runtime and identify which values can be written or read across sessions. Runtime credentials should be checked for permissions beyond package retrieval, especially metadata or management operations.
They should also review connected-app reads. Can the user see which resource will be accessed before the action occurs? Is authorization tied to the current task and requesting identity? Can a hidden or inherited instruction trigger the read? Do logs preserve the instruction source, tool call, returned data category and destination?
Finally, teams should exercise the full failure path. Revoke or isolate a session, rotate credentials, search for unexpected cross-session identifiers and verify that an investigation can distinguish a blocked attempt from completed data access.
Maetra analysis
The central governance lesson is that authorization must follow the complete action path. A network sandbox can work as intended while shared state creates a separate route around the isolation assumption. A tool permission can be valid for the user while the instruction invoking it comes from an unauthorized source.
The practical control unit is therefore not just the container or connector. It is the combination of tenant, session, instruction source, tool, resource, purpose and destination. Recording and enforcing that envelope makes hidden task execution harder and gives investigators useful evidence when a boundary fails.
This report is a strong reason to retest shared infrastructure and connected-app permissions. It is not evidence that the closed channel remains exploitable or that customer accounts were broadly compromised.