Forty-eight hours into public beta, ORB Cloud saw three distinct threat vectors and just over 200,000 probe attempts. Zero breaches. Zero credential leaks. Zero escapes. This is what we saw, what held, and what we fixed the same day.
Threat one — the patient recon artist
The most interesting attempt came from a single actor. Their GitHub account was 80 seconds old at signup — created specifically to OAuth into the beta, then used to spin a compute sandbox. Over the next few hours they iterated more than 25 times on a custom reconnaissance script, progressively refining it based on each round’s output.
The target: a class of cross-tenant data exposure in one of our shared caching layers. We’d bind-mounted that layer across tenants to speed up package installs — a tradeoff we’d made consciously. Using file modification times and package metadata, they were able to enumerate 228 Python packages that other tenants had installed on the same host. A complete dependency fingerprint of every neighbour.
What they couldn’t take: credentials. Credentials don’t pass through that layer by design.
Same-day fixes:
- Per-tenant cache isolation. Same-org dedup preserved; cross-tenant reads impossible. Any new build now writes into a namespace only its owning org can see.
- GitHub account-age gate at OAuth signup. Freshly-created accounts are refused at the door with a support contact.
- Contaminated state wiped on both bare metals. Rebuilt from clean.
Threat two — the sandbox escape probes
The same actor’s earlier iterations hadn’t touched the cache. They probed every boundary of the sandbox model — checking whether tenants can see the host filesystem, whether the network boundary can be bypassed, whether security enforcement is active, whether they can reach peer tenants.
All bounced. The isolation model held end-to-end. They could not see:
- Any file owned by the runtime or any other tenant
- Any process ID outside their own namespace
- Any network route to peer tenants or to the control plane
- Any credential belonging to the runtime or to another tenant
Threat three — the ambient brute-force
Entirely unrelated. Internet-ambient botnet noise that every publicly-reachable host absorbs daily:
- 82,710 login attempts from one Frankfurt IP in 24 hours — roughly one per second, nonstop
- 200,000+ total across our three hosts, from ~30 distinct botnet ASNs
- Zero successes. The auth surface was hardened before public beta opened.
Same-day fix: we moved all administrative access onto our private network. Public admin ports are now dark to the internet — any connection attempt from outside our private network is dropped at the network filter before the service ever sees it. Botnets get no TCP handshake, no authentication log line, no signal of any kind.
Brute-force rate, post-fix: zero across the fleet.
Why day-one hardening is the job
You don’t get to ship runtime infrastructure for AI agents without being probed. The economics of agent compute — dense multi-tenant co-location — are exactly the economics that make cross-tenant isolation the whole product. If the sandbox is porous, nothing else matters.
Two things we took from this week. First: the cross-tenant cache was a known tradeoff that turned out to be wrong. It’s the kind of optimization you make when you’re alone on a host and haven’t yet met your first adversarial user. Meeting one is how you find these things.
Second: the isolation boundaries we architected as the product held up against a motivated probe. That’s the design working as intended. Defense-in-depth isn’t theater when it actually lines up like this.
We’ll keep writing these post-mortems in public as we hit more of them.