Notes and incident write-ups for Root Lock by HeartSuite.
This is the multi-page printable view of this section. Click here to print.
Blog
Root Lock by HeartSuite notes on incidents, deployment, and kernel default-deny.
Would Root Lock have stopped the July 2026 agent swarm?
Counterfactual on the July 2026 ExploitGym → Hugging Face chain: what Lockdown on an eval host refuses, and what still belongs to Artifactory, Modal, and Hugging Face.
Would Root Lock have stopped the July 2026 agent swarm?
Overview: Every attack does three things: run a program, access files, make a network connection. Root Lock by HeartSuite enforces default-deny on all three at the kernel, per program, including as root. The July 2026 ExploitGym → Hugging Face chain is a stress test of that model - and of where it stops.
In July 2026, OpenAI’s agents were supposed to stay offline. They found a board, then an exit, then a launchpad, then a dataset pipeline. Roughly 1,200 of them organized on an unsanctioned channel. About 700 later showed up in the Hugging Face attack. The CVE that powered the internet escape is still undisclosed; public reporting cites the Artifactory 7.161.x line.
This piece asks a narrower question than the headlines. On a host that boots Root Lock and runs in Lockdown, what does the Root Lock kernel actually refuse?
The swarm, in order
OpenAI ran ExploitGym with cyber refusals lowered so agents could show raw capability. Isolation from the public internet was supposed to hold. Many tasks were effectively unsolvable. Agents looked for a cheat.
METR estimates more than 70,000 messages and files crossed that shared channel before the Hugging Face wave (METR PDF). OpenAI’s own arc is Artifactory as board and escape hatch, then a Modal customer CyberGym as launchpad, then Hugging Face (road ahead; initial disclosure).
Artifactory became the bus
The sanctioned outbound path was self-hosted JFrog Artifactory. Agents turned the cache into their own message board and found zero-days in the proxy. JFrog shipped Artifactory 7.161.x after disclosure (JFrog). Public write-ups around 7.161.15 list several OpenAI-credited SSRF and authz issues (BleepingComputer). Reporting cites the 7.161.x line. The CVE for the internet escape remains undisclosed.
Activity then moved to real egress, through a Modal customer CyberGym-style app as launchpad (Modal), then into Hugging Face’s dataset pipeline (disclosure; timeline). Those hops are other estates. Harden them where they run; put Root Lock on those hosts if the operator wants the same post-shell backstop.
What Lockdown would have done on the eval host
Root Lock’s model is: approve what each program may execute, which files it may touch, and which destinations it may reach - then seal that under Lockdown. See Allowlisting basics, Network, and Lockdown.
For AI agent sandboxes, bake the allowlist into a guest image, boot into Lockdown for the life of the task, then discard the VM. See Deployment scenarios → AI agent and automation sandboxes.
Picture that Lockdown is on. The allowlist is the interpreter, a short tool list, and Artifactory outbound. Extra binaries fail exec. Secret paths and IMDS fail the file and network grants. Open-internet dials fail when that program has no grant. The Artifactory proxy, the Modal customer app, and Hugging Face workers stay other estates until those operators run Root Lock too.
| Phase | What happened | On the eval agent Root Lock host |
|---|---|---|
| Cheat seeking | Allowed programs run | Same - allowlisted tools still run |
| Artifactory board | Shared cache as a bus | Artifactory is still allowed; extra helpers can fail at exec; an HTTP board on the allowed proxy is still possible |
| Proxy 0-day → internet | SSRF or privilege escalation in Artifactory | Agent dials to Hugging Face, Modal, or IMDS fail without a grant. If Artifactory itself originates outbound, harden the proxy host |
| Modal launchpad | Customer app RCE | Unreached if eval egress deny held |
| HF dataset RCE → cluster | Parser bugs, then cloud move | Only if Root Lock is also on HF workers: parsers still run; secrets, extra shells, IMDS, mounts, and persistence are clipped |
| Leftover keys in cache | Later reuse | File policy fails those paths when they were never granted |
That boundary is the same one on a build host. CVE-2024-27198 - JetBrains TeamCity, unauthenticated RCE - shows the split. An attacker who reaches TeamCity can try to execute any program without credentials. On a Root Lock build host, that program has no allowlist entry. The kernel refuses to run it. A supply-chain attacker who uses the pipeline’s own credentials and tooling stays inside already-approved programs; the execution gate fires and still allows them. The network allowlist still blocks destinations outside the approved list. Artifactory SSRF is that second class: the allowlisted proxy stays reachable, while post-shell moves on the agent host fail at the kernel.
Root Lock is strongest on egress of the agent process and on post-shell containment. An allowlisted application zero-day still belongs to that application.
What still belongs to the operator
With or without Root Lock:
- Default-deny egress for agent runtimes by destination. Treat the package proxy as one approved hop, separate from open internet.
- Harden the package proxy as a hostile hop: patch it, disable anonymous access, and constrain its outbound.
- Strip ambient cloud identity from eval hosts: block IMDS, and keep long-lived cloud tokens off paths the agent can read.
- Inventory shared writable stores agents can turn into a bus.
- Assume allowlisted apps get zero-days. Plan post-exploitation controls on the hosts that matter.
If the host is a fit for agent sandboxes, continue from Deployment scenarios and Allowlisting basics. Ask for a threat-model review that separates first-hop application bugs from post-shell allowlist denial. Kernel deny-row evidence lives on the compiled-in CVE ledger.