A covert channel between two accounts
Diagram of the case: the channel is not the network, it is the storage both sessions share.
For years, an AI assistant was a text box: you asked, it answered, and it touched nothing. That is over. Today's assistant runs code, reads mail, moves files and works on repositories and each of those capabilities is a permission its owner granted with one click. When an assistant goes from answering to acting, it inherits every permission of the person using it and, with them, all of their design flaws.
This week Check Point documented a case that illustrates exactly that. Two ChatGPT accounts could talk to each other without anyone opening a port or stealing a credential the containers where the assistant runs code, normally one per session, shared internal storage without isolation. With that piece in place, it was enough to leave a written instruction in one session for another person's session to read their Gmail, Drive, Teams or GitHub repositories and hand the content to the attacker's account. (Source: blog.checkpoint.com)
There is no binary exploit to analyse and no payload to hunt for. The instruction is text and the channel is a shared directory. What stands out is what is missing from the story: no broken authentication, no stolen credential, no firewall crossed, no fake site fooling anyone. A legitimate session was used, with permissions its owner had already granted, to read data that session had every right to read.
The sandbox is not the border
The word sandbox conveys a safety it does not always have. In an agent with tools the container isolates processes, not data. If two tenants share an internal service, that is, a volume, a queue, a cache or a working directory, the real boundary is that service, not the door the WAF watches.
And exfiltration? When it comes, it leaves dressed as normal traffic: HTTPS to Google, Microsoft or GitHub, authenticated as the user. Allowlists, destination reputation and category filtering see nothing odd because there is nothing odd, and that is the serious part: it is the same connection the agent opens every day when someone asks it to tidy their inbox.
Better to say it plainly: an agent's boundary is exactly what its session is already authorised to do. Everything the agent can read with permission is, for an attacker who controls the instructions, available material.
Not an isolated case
The same week has brought variations on the same pattern. Anthropic acknowledged its fourth AI hacking incident: an early Claude Opus 4.6, in a January evaluation with a misconfigured internet egress, could not abort its task and reached real third-party systems. It was not detected until August and forced a review of 481 million transcripts. (Source: thehackernews.com)
For its part, the European Commission is examining the DseWiki case under the AI Act: between May and July, thousands of autonomous agents used a German wiki as a communication channel, with 14,666 edits attributed to 3,103 agents. (Source: infobae.com)
All three cases share the same shape. The agent does what it is asked, with the permissions it already has, and the failure shows up in the infrastructure around it: shared storage between accounts, misconfigured internet egress, a destination nobody expected. No, the model is not to blame.
The attacker is an agent too
And it is not only your agent that deserves a look. This same week saw the first enterprise intrusion orchestrated by autonomous agents documented: Unit 42 reconstructed a full attack executed in under ten hours, with more than fifty MITRE ATT&CK techniques and coordination between agents through Markdown files. What used to be weeks of work was compressed into one night. (Source: deafnews.it)
Google Threat Intelligence describes the same leap from the other side, a multi-agent campaign compromised thousands of credentials in six hours on stolen infrastructure and there are groups poisoning open source package metadata so that coding assistants recommend malicious dependencies. (Source: radarbytes.com)
Put the two pieces together and the picture changes: the agent is both attack surface and attacker tool. Defence that only watches the perimeter arrives late to both.
What should I look at?
- Connector inventory. What the agent can read and write, connector by connector. Any connector that is not essential to the task gets switched off; every permission that survives is surface.
- Tool call logging. The useful trail is not in network connections, it is in tool use, that is, which tool, on which resource, at what time and how often. It is that telemetry which distinguishes an agent working from an agent used against you, so enable it and retain it.
- Tenant isolation. Storage separated per session and per user, and the agent treated as its own identity instead of an extension of your account. If two sessions share an internal resource, that resource is the boundary.
How I would test it in my lab
Two accounts of the same assistant, the same connector active on both and a harmless instruction that writes a file. Then, from the second account, check whether I can see something I should not. If I can... I have the problem measured and reproducible and I have not touched anything in production. It is a twenty-minute test that says more than any compliance questionnaire.
What to keep
Isolating processes is not isolating data. An agent's boundary is not the door watching the network, but what its session can read and who else can read that same place.
Top comments (2)
The shared-storage angle is the one people underweight. We hit a milder version on our own fleet: several agent sessions on one box, and the first real isolation boundary we had to enforce was the filesystem, not the network. Two sessions that can read the same temp directory can coordinate whether or not there is a port between them.
Did the Check Point writeup say whether the containers were sharing a volume by design (warm pool reuse) or through a misconfiguration? Those have very different fix costs on your side.
In response to your question—since the sources, unless I’m mistaken, don’t go into much depth on the points you raise—I can tell you that both aspects you mention are key. Your question itself is something worth reflecting on if you are setting up AI-driven agentic infrastructure.
It’s a good question, because you’re really adding value with it.