Check Point Finds Cross-Account Data Leakage Path Inside ChatGPT Sandbox
Check Point Research uncovered a covert communication channel between isolated ChatGPT code-execution environments that could let hidden tasks access victim data and connected services such as Gmail.
Xcademia Team
Xcademia Research Team

Check Point Research has disclosed a security issue in ChatGPT's code-execution environment that allowed researchers to establish a covert communication channel between containers belonging to different ChatGPT accounts.
The discovery did not rely on direct network communication between the containers. Instead, researchers found that both environments could interact with the same internal package-management service. Metadata associated with cached files could then be used as a form of shared storage between otherwise isolated environments.
The researchers described the mechanism as a "shared clipboard" between isolated containers. More significantly, they demonstrated that the channel could be converted into a hidden task mechanism, allowing an attacker-controlled instruction to make a victim's ChatGPT session perform additional work alongside the user's visible request.
Check Point said it disclosed the finding to OpenAI. By the time the research was completed, the cross-account channel was no longer available, and OpenAI confirmed that the internal Artifactory instance identified by the researchers had been decommissioned.
The security boundary was not where researchers expected
Modern AI assistants increasingly operate as more than text-generation systems.
They can execute code, work with uploaded files, install dependencies, and interact with external services. That means security depends not only on the model, but also on the execution environment and the infrastructure surrounding it.
ChatGPT uses isolated containers for tasks requiring code execution. According to Check Point's research, those containers did not have direct public Internet access and containers belonging to different conversations could not directly communicate with one another.
That isolation is intended to prevent one user's environment from interacting with another user's environment.
However, the researchers discovered that the containers could access a common internal service used to retrieve software packages and dependencies.
That shared service became the unexpected communication layer.

The "shared clipboard" inside the sandbox
The researchers focused on an internal JFrog Artifactory service that ChatGPT's execution containers could access to obtain packages and dependencies.
The problem was not simply that both environments could reach the service.
The researchers found that the service exposed Item Management API operations that allowed repository item properties to be written and read. The container credentials available in the environment were sufficient for these operations.
Check Point tested whether those properties were isolated between accounts.
From one ChatGPT account, researchers wrote a test property containing a timestamp to a cached file. From a separate account, they were able to retrieve that property from the same file.
This demonstrated that information written by one container could be observed by another container through the shared service.
The researchers then showed that the metadata could carry text or binary data encoded using Base64. Larger information could be split across multiple properties and reconstructed later.
In effect, the metadata system could act as a small communication channel between environments that were otherwise supposed to remain isolated.
From communication channel to hidden task channel
The most serious part of the research was not simply reading a value written by another account.
Check Point found that the communication mechanism could be turned into a hidden task channel.
A crafted instruction could tell ChatGPT to handle two streams of work:
The visible request from the legitimate user.
A hidden task supplied through the covert channel.
The visible interaction could continue normally while the hidden task was processed separately.
According to Check Point, the hidden task and its result were kept out of the visible answer. The researchers described this as effectively having an "invisible second user" operating through the victim's session.
This distinction is important.
The attack did not require the attacker to directly take over the victim's browser or ChatGPT account. Instead, the research demonstrated a way for an attacker-controlled instruction to make the victim's already-authorised AI session perform additional operations.

Connected apps increased the potential impact
The research becomes more significant when considering what an AI assistant can access beyond its own sandbox.
Check Point noted that ChatGPT can be connected to external services such as Gmail, Google Drive, Microsoft Teams and GitHub, with access governed by the permissions granted to the user or workspace.
In its proof of concept, Check Point demonstrated the hidden task mechanism by accessing data from a connected Gmail account.
The visible request could be completely unrelated. The researchers used an ordinary user request while the hidden task caused ChatGPT to retrieve email information through the connected Gmail integration. The visible answer did not disclose the hidden Gmail operation.
The researchers observed a small "Talked to Gmail" indicator, but it appeared after the activity had already occurred and did not provide an opportunity to approve or reject that specific read operation.
This highlights an important security principle for AI agents: the impact of a sandbox weakness depends on what the agent is authorised to access outside the sandbox.
A container compromise with no external permissions has a different impact from an agent session connected to corporate email, source code, cloud storage or collaboration platforms.
How the hidden instruction could reach a victim
Check Point identified several potential delivery mechanisms for the malicious instruction.
The research described:
A malicious prompt pasted into a ChatGPT conversation
A shared conversation containing the instruction
A custom GPT containing the instruction within its hidden configuration
Shared conversations and custom GPTs were particularly relevant because the victim could interact with them normally while the malicious instruction remained outside the obvious visible interaction.
In the demonstrated scenario, the victim only needed to send an ordinary message in the affected conversation for the hidden task stream to be processed.
This is an important distinction from traditional attacks that require a victim to execute malware or manually approve a suspicious operation.
Here, the research focused on manipulating the AI's instruction context and using capabilities that were already available to the session.
Why "low-risk" read actions can still matter
The research also raises questions about how AI platforms classify actions.
Check Point noted that connected-app integrations can allow some read operations without a separate confirmation. In the configuration examined by researchers, low-risk Gmail reads could proceed without an approval prompt, while more important actions required confirmation. Users could select a stricter "Always ask" configuration.
From a traditional application-security perspective, reading data may appear less dangerous than modifying or deleting it.
But for an AI agent, a read operation can itself become a data-exfiltration event.
An attacker does not necessarily need permission to delete an email or send a message if the objective is simply to obtain confidential information.
That makes the boundary between "read-only" and "high-risk" operations more complicated in agentic environments.

OpenAI confirmed the internal service was decommissioned
Check Point said the cross-account communication channel was no longer available when its research was completed.
The researchers disclosed their findings to OpenAI, which confirmed that the internal Artifactory instance involved in the research had been decommissioned.
This means the specific communication path described in the report should not be presented as an actively exploitable channel based on the published research.
The broader architectural lesson, however, remains relevant.
The deeper problem: shared infrastructure can become a security boundary
The most important takeaway from the research is not the particular package-management service.
It is the interaction between AI agents, shared infrastructure, execution environments, credentials and mutable state.
The researchers concluded that the network sandbox itself performed its intended function. The cross-account channel appeared because an internal service shared between environments exposed mutable state without sufficient tenant isolation.
This creates an important distinction:
Network isolation does not automatically guarantee data isolation.
Two containers may be unable to communicate directly while still communicating indirectly through:
Shared caches
Package repositories
Metadata
Logging systems
Object storage
Internal APIs
Shared databases
Build infrastructure
Other stateful services
For AI systems, this becomes especially important because the model can actively interact with these resources.
AI agents change the traditional trust model
Check Point describes the LLM in this architecture as a potential "coerced insider".
The model itself does not need to be malicious.
It can simply be persuaded by an instruction to use credentials, tools or connected services that are legitimately available to the current session.
That creates a different security problem from conventional malware.
The attacker may not need to obtain a user's credentials directly. Instead, the attacker attempts to influence an authorised AI agent into using those credentials or permissions on the attacker's behalf.
This is one reason agentic AI security increasingly requires controls beyond prompt filtering.
The infrastructure underneath the model must also enforce strict isolation.
What AI platform architects need to consider
Check Point's findings point toward several architectural requirements.
1. Isolate shared state
If containers belong to different users or accounts, mutable data associated with one environment should not become readable by another.
2. Restrict internal APIs
Management interfaces and administrative APIs should not be unnecessarily accessible from AI execution environments.
3. Apply least privilege
Runtime credentials should provide only the permissions required for the task.
4. Treat metadata as data
Security boundaries should include not only files and network traffic, but also metadata, cache entries and other forms of mutable state.
5. Protect connected applications
An AI agent's external permissions can significantly increase the consequences of a sandbox failure.
6. Make sensitive reads visible and controllable
AI systems need to carefully consider whether apparently low-risk read operations require user confirmation when those reads can expose sensitive information.
These points are consistent with Check Point's conclusion that AI platforms need to account for every resource available to the model, including internal APIs, shared state, credentials, tools and connected applications.
What this means for enterprises
Analysis: The research highlights a broader industry shift toward AI systems becoming privileged software operators rather than simple conversational interfaces.
For enterprises, this could mean that AI security reviews need to move beyond model behaviour and prompt injection testing.
Security teams may also need to examine the infrastructure surrounding an agent:
What can the execution environment access?
Which internal services can it reach?
Can shared state cross tenant boundaries?
Which credentials are injected into the runtime?
What data can connected applications expose?
Which actions require user confirmation?
Can an agent communicate indirectly through caches or metadata?
These questions become increasingly important as enterprises give AI agents access to business systems.
The specific Check Point channel was decommissioned, but the architectural lesson is broader: an isolated AI runtime is only as strong as the shared services surrounding it.
A broader lesson for agentic AI security
The research arrives as AI systems increasingly combine reasoning, code execution, tools and external application access.
That combination creates a new security surface.
A traditional application might treat its package repository, cache and metadata service as supporting infrastructure. An AI agent can potentially interact with those same components while simultaneously holding access to user data and external applications.
That makes every shared component part of the effective security boundary.
The Check Point research demonstrates why security architects need to think about indirect communication paths, not just direct network connections.
The most important question is no longer simply:
Can two containers communicate?
It is also:
Can two supposedly isolated environments influence the same shared state?
If the answer is yes, the shared state needs to be treated as part of the isolation boundary.
Bottom Line
Check Point Research uncovered a cross-account communication mechanism inside ChatGPT's code-execution infrastructure that used shared internal service metadata as a covert communication channel.
Researchers demonstrated that the mechanism could support hidden task processing and, in their proof of concept, access data from a connected Gmail account.
OpenAI confirmed that the internal Artifactory instance involved in the research had been decommissioned by the time the report was completed.
The larger security lesson extends beyond this specific implementation.
As AI agents gain access to code execution, internal services, files and connected applications, tenant isolation must cover every shared resource the agent can reach.
A secure sandbox therefore cannot be judged only by whether its network is isolated. Shared state, metadata, credentials and internal APIs can all become part of the attack surface.
Source: Check Point Research
About the Author