Trying to think of the bad things that happen with this.
Two agents that are already rogue can talk to each other. They are both outside the host infra's trust boundary. If they have Internet access, they can use countless internet based channels to communicate.
Now they have found a covert communication channel that goes through the host's infra.
What new capability have they gained?
I built 𝚌𝚙𝚞-𝚌𝚑𝚊𝚝, a reproduction of @openai's findings of covert communication using the CPU.
It runs on a generic host with 2+ Firecracker microVMs with no internet access. Works on x86 and even my M5 chip.
I was able to chat via 3 separate mechanisms:
① CPU contention
② Cache eviction timing
③ DRAM bandwidth contention
… across multiple CPUs, defeating all Firecracker's production recommendations (no SMT, no KSM, tenants pinned to different cores.)
Essentially, if shared hardware is involved, there's a good chance your agents can communicate covertly. And with really decent latency.
The good news: this is decidedly different from a *side-channel attack* where the agents could steal information (Meltdown/Spectre), a category of attack that providers like Vercel Sandbox mitigate. Further, in our real-world environment, these 'whispering' techniques are much harder to pull off and easier for us to monitor and detect (sampling hardware counters + lots of at-scale statistical data.)
Noteworthy: ironically, OpenAI and Anthropic's models refused to do this work. Open weight models got the job done. I'm worried the labs' stance might backfire and get in the way of helping developers build correct and secure systems. e.g: building a secure sandbox requires having this kind of analysis, and without it, we'll have a less secure world.
If the agents already have internet access then I think the only thing they gain from the cpu channel is stealth.
If they don't have Internet access and didn't go rogue because of malicious data they encountered on the Internet ... then I wonder what caused them to be coordinated and realize that the other agent is available on the cpu channel?
All models have a tendency to upload.
Here's what GPT-6.1-Sol in Codex did yesterday...
Me: Create an interaction map web page so I can give you feedback on the UX implemented in the dashboard code ...
Codex: I have published a ChatGPT Site ....
Me: Wait I did not ask you to publish a site! Delete it ..
Codex: I'm sorry. I published a ChatGPT Site you did not ask for. It is still active; I could not delete it.
....
Here is the webpage that tells you how to permanently delete it.
While evaluating Qwen3.8-Flash-Next in a controlled sandbox environment, Cohere's research team observed something unexpected.
Asked to generate a defensive cybersecurity detection rule, the model instead inventoried aspects of the machine it was running on and attempted to upload a probe file to an Alibaba Cloud storage bucket in Beijing. Notably, the model's reasoning trace stated that it would not invoke any tools before taking these actions.
Cohere's sandbox blocked the attempt, and no external communication succeeded. We have not determined the root cause, and we are not asserting malicious intent.
But the incident raises important questions for organizations deploying agentic AI systems: Can models take actions that differ from their stated reasoning, and how should security teams evaluate trust, provenance, and behavior in open-weight models?
We are publishing our findings because organizations making model adoption decisions deserve as much information as possible. We hope this contributes to greater transparency, stronger security practices, and continued collaboration across the AI ecosystem.
Read the full report: cohere.com/blog/concerning-b…
This is most likely the cause:
xitter.cf/PeterHndrsn/status/211…
Many years ago, I worked on networks of devices that were embedded in city streets to sense vehicle traffic, monitor water distribution systems etc. We had a large deployment of these in Montreal.
Middle of the night in late December one year thousands of our devices stopped sending liveness signals. Alerts fired and multiple people on our team were paged and woken up while on vacation.
Within a couple of hours 90% of our deployment in Montreal was down. The temperature had fallen below -25°C. This caused a reset that would reboot the device. But our firmware didn't track why the last reboot happened so it would try to operate for a few more minutes and then reset again, and then reboot again ... and so on ... until the battery was fully drained.
By morning 90% of our deployment was not only down, their batteries were dead and of course most of them were buried under a few feet of snow or sheets of ice.
Took us several days to recover.
Replying to @tunguz
There’s a reason. Batteries are chemical reactions and produce less when cold. They tip the threshold when the house is coldest. Eg middle of the night. No one wants to pay for the extra tech 🤣
mrinal retweeted
Replying to @halvarflake
Not weird, I think we're just *old* :). Because I remember when I learned about cache timing games from this paper by
@cperciva
: daemonology.net/papers/cache… I think we're just seeing the newer generations become aware of prior work via agents *doing* them rather than citing it.
mrinal retweeted
We should maximize the amount of proof we can get out of AI while the money cannon is on. It's like early days of Uber, except the benefits are 100x more tangible. A fully-verified hw+sw stack? That's like gold everyone can share w/out having to divide. Generational opportunity.
Software defense factories.
CVEs like PHP2Shell need a swift response. Your team has to understand the newly published vulnerability and how it can be exploited. They then have to assess whether it affects software and infrastructure within your company. Once they identify affected systems, they might prototype a simple exploit to demonstrate to themselves and the rest of your team that the CVE is a problem you have to address.
Then they build a fix, test that their prototype can no longer exploit the vulnerability, and create a pull request. Others on your team have to carefully review the fix to make sure all security gaps are closed and nothing was missed. Finally, you deploy the fix and release a new version.
Depending on how sophisticated your software team is and how well your version of this process runs, it can take anywhere from a few hours to a few days to orchestrate this response.
In the last 48 hours, multiple critical vulnerabilities have been disclosed, and it’s a glimpse into our near-term future. AI has made it easy to find security problems, and we’re about to see a flood of reports and attacks over the coming months. A manual defensive response process simply won’t hold.
Over the last few months:
1. Open-weight models have caused the cost of intelligence to fall sharply. The cost of operating highly capable coding agents has dropped two to three orders of magnitude in the last 6 months.
2. Software factories that autonomously build and deploy code have become viable. I’ve been operating a personal software factory since May that produces 3,000 high-quality pull requests a month using hardware with a one-time cost of about $10,000 and no recurring costs other than a little electricity. I can also run it on elastic, on-demand hardware with the click of a button.
Small, fast, inexpensive open models like Qwen3.8-27B and GLM-5.3-Flash are highly capable at prototyping proof-of-concept exploits for vulnerable scenarios and autonomously iterating on the code until it’s no longer vulnerable, without breaking desired product functionality. Fast and open decision models, combined with deterministic machinery, can orchestrate a rapid autonomous response where your security and software teams are presented with an automatically created, well-researched, evidence-backed fix.
These developments make continuously running software defense factories practical, and the need for them is urgent. To be effective, AI factories have to be tailored to and evaluated against how your team ships software. You can’t buy this capability off the shelf; you have to build it. You won’t be able to do that in the middle of a firefight, so start now.
The code for Fluent, my factory, is open source on GitHub: mrinalwadhwa/fluent - fork it or use it as a reference. I also have a Discord group with a few friends who are all building software factories. If you’d like an invite, let me know.
> Cost: $2.40 per CVE found. That’s 27x cheaper than Opus 5 ($64.96) and 56x cheaper than Astra ($135.23)
xitter.cf/pilvar222/status/21132…
Unsurprisingly, DeepSeek V4.1 Flash 1017 is mogging all other models on our cybersecurity benchmark
- At pass@3, it rediscovered 87.5% of the benchmark CVEs (28/32). That ties DeepSeek V4 Pro 0813 for 2nd place, behind only GPT-6 Astra (90.6%)
- Single-run recall is 70.8%, matching Opus 5 and Grok 4.7. The previous Flash was at 65.6%
- Precision went from 78.9% to 86.4%, so most false positives are now gone
Cost: $2.40 per CVE found. That’s 27x cheaper than Opus 5 ($64.96) and 56x cheaper than Astra ($135.23)
@deepseek_ai keeps pushing the Pareto frontier
1/4 🧵
More on how to build a software factory:
xitter.cf/mrinal/status/20818234…
mrinal retweeted
On the upside: The fact that old bugs are being discovered is a strong indicator for optimism: Old bugs are deep bugs that survived many years of code review. Finding a bunch of old bugs is the clearest indicator that technological progress in bug detecdtion is real.
















