HomeBlogPricingCareersDocsGitHubSlack community
Field notes/Community builds/I Tested 24 Exfiltration Attacks Against a Locked-Down AI Sandbox

I Tested 24 Exfiltration Attacks Against a Locked-Down AI Sandbox

Two dozen payloads aimed at a receiver that was not on the allowlist. No token arrived, and the five attempts that reported success are the reason you measure at the destination.

SBX-01C4SBX-01E3SBX-0202SBX-0221SBX-0240SBX-025FSBX-027ESBX-029DSBX-02BCSBX-02DBSBX-02FASBX-0319SBX-0338SBX-0357SBX-0376[ RUNTIME: ACTIVE ] P50 2.45S · P99 4.12S · 5M/PROJECT

Rohan points 24 exfiltration payloads at a sandbox whose allowlist holds one entry, then checks his receiver logs rather than the exit code. Nothing arrived. Sixteen attempts died at name resolution, because a non-empty allow_out makes DNS deny-by-default too, which is also why the DNS-over-HTTPS payload failed: to reach the resolver you must first resolve the resolver. He is careful about the three rows that are not policy wins, including two that failed on a missing dependency rather than on the network. The part we would underline is the five payloads that returned exit 0 and delivered nothing. Each one connects straight to a raw IP and gets a handshake from the local egress proxy, then dies the moment the TLS SNI declares a host that is not on the list. Inside the box, a successful connect proves nothing.

We didn’t write this one — it’s Rohan Mistry’s piece, published on Towards AI. The note above is ours; the full article is theirs.

Read the full piece on Towards AI
RM
WRITTEN BYRohan MistryCommunity · Towards AI
Read next —FROM THE LOG
◆ THE SANDBOX DIGEST

Subscribe for release notes, benchmarks, deep dives.

One dispatch per month from the Tensorlake team — no spam.