The New Stack recorded in July that AWS, Google Cloud, Microsoft Azure, and Cloudflare all now sell sandboxes for AI agents. A sandbox is a sealed environment where code an AI writes or runs can execute without touching anything else. The article split the problem in half: isolation, meaning the walls of the sealed environment, and governance, meaning the rules about what the code inside may do. That artificial division is useful as a teaching model. As a description of what the vendors have shipped, it is already inaccurate, and the vendors’ own documentation is sufficient to show their failures.

Google announced Cloud Run sandboxes on July 9, and the announcement describes how they behave. Code inside the sandbox can make no connection to the internet unless the operator switches connections on for that single run. The code can read the files it was given, and anything it writes is thrown away when it finishes. It cannot see the settings and credentials of the service that launched it, and it cannot ask Google’s internal credential service for an identity. Consider what these four restrictions are. They are rules about what running code may reach. In the article’s division, rules belong to governance, and governance was supposed to be a separate layer above the walls. Google has built these rules into the walls. What Google built in is also crude. Internet access is fully off or fully on. There is no way to permit one site and refuse another. Only the simplest rule, the default of no access, has moved inside the walls. Anything more detailed still has to be enforced somewhere else.

The AWS announcement takes a moment to describe because the arrangement is unusual. AWS published a developer guide for running Anthropic’s Claude Managed Agents on Lambda MicroVMs, a new AWS service that starts a small isolated virtual machine for each job. AWS files this under the name “self-hosted sandboxes.” Here is what happens, step by step, according to the guide. A work session is created and held on Anthropic’s computers. Anthropic then sends a notification to a web address in the customer’s AWS account. A small program at that address checks the notification is genuine and starts one virtual machine. The program inside that machine contacts Anthropic, asks for the job, runs the commands the job requires, sends the results back to Anthropic, and shuts down. The guide states the division in its first paragraph: “Anthropic hosts the agent loop and Claude model,” and the customer’s machine is where the commands run. In plain terms, the customer owns and pays for the computer. Anthropic decides when the machine wakes up and what it works on. Everything the machine produces goes back to Anthropic.

Anthropic’s own documentation says the same thing. The “self-hosted” environment is described as a queue of jobs, and the queue lives with Anthropic. The customer’s machine asks the queue for work and reports back when the work is done. So the term “self-hosted” covers one thing: the commands run on the customer’s hardware. The session itself, its state, its schedule, and the decision that there is work to do at all stay with Anthropic.

The guide’s own troubleshooting table shows how complete the dependency is. One listed problem is a worker that shuts down the moment it starts. The listed cause is a machine blocked from reaching api.anthropic.com. The machine has one essential need, and that need is a line to the vendor. The networking section explains why this rarely goes wrong in practice: AWS gives these virtual machines open internet access by default, so nothing has to be configured for the machine to reach Anthropic. Now compare the two defaults. Google ships its sandbox with the internet switched off, because Google treats the code inside as the danger. AWS ships this sandbox with the internet switched on, because the arrangement stops working the moment the machine loses contact with Anthropic. Each vendor chose the default its own design required.

The AWS design deserves some credit, because giving it helps clarify the failures by others. Anthropic issues two kinds of key. The powerful one, which can create new sessions, stays with the customer’s operator and is never placed on any AWS machine. The virtual machine receives only a lesser key, enough to collect its assigned job and report back, and even that key is fetched at the last moment rather than stored on the machine. This is a statement of trust. The customer’s machine is trusted to carry out work. The power to create work is kept away from it.

So the vendors’ own published record is all we need to prove how broken they are. Google has moved rules inside the walls. Anthropic and AWS have moved the decisions outside the customer’s premises altogether. The walls themselves are genuine, and they are the least disputed part of either product. The questions that decide what actually happens, what the code may reach and who tells it what to do, are answered somewhere else: at Google, baked into the walls as fixed settings; in the AWS pattern, on Anthropic’s side of the line. A buyer who inspects only the walls has inspected the one part every vendor already agrees on, and left out the part that decides what the machine does.

The first thing that jumped out at me in a post about the famous “Pelican on a Bike” test is that GPT-5.6 Luna is being used to score GPT-5.6 Terra, without any inter-run reliability check.

In other words, given a within-lab design, there is a style-level bias test but not a cell-specific bias, which is in fact the thing supposed to be under test.

The second thing is the entire audit cost $80 across seven frontier models. Independent falsification of a contamination hypothesis is very inexpensive. No cost and all the code and data published means we should be seeing a lot more of this. Cheap external verification is demonstrably feasible, again.

Remember all the noise about Mythos being a marketing scam? Any vendor benchmark that can’t be independently checked is a cynical design decision that deserves heavy pushback and scrutiny.

Anyway, the point of that post seems to be that any lab gaming the Pelican on a Bike benchmark competently games the whole category, not the individual cell. This is the same structure we see in any signature-based detection generally: it catches a weak or clumsy version only.

UN investigations explain how it’s like a PayPal of the sky.

Starlink low-earth orbit terminals, has decoupled criminal operations from local telecommunications infrastructure, enabling scam compounds and other illicit facilities to operate in remote or enforcement-sensitive zones without dependence on terrestrial internet or power infrastructure that host governments might sever.

On July 28, 2026, the FCC’s Public Safety and Homeland Security Bureau released Public Notice DA-26-786. It’s completely broken.

The notice adds two categories of equipment to the Covered List:

1. Power inverters produced in a foreign country
2. Advanced robotic devices produced in a foreign country

The Covered List identifies equipment the government has determined poses an unacceptable risk to national security. Devices on the list cannot receive FCC equipment authorization, which means they cannot legally be sold in the United States. The bans rest on two National Security Determinations sent to the FCC one day earlier by a White House interagency body. The FCC treats these determinations as binding and says it is required to place the equipment on the list.

To put it simply, a threat is described and then a rule is written that has nothing to do with that threat. It’s easy to see where they screwed this up so badly, and maybe even why.

The FCC names two risks.

1. Supply disruption, meaning foreign suppliers could choke off the flow of inverters and robots at a time of their choosing.
2. Remote access, meaning foreign actors can reach these devices over the internet. They can shut them down remotely, pull data off them, or use them for surveillance.

Then the rule bans devices based on where they were manufactured. Record scratch.

Remote access does not depend on where a device was manufactured. It depends on how the device connects, who controls its software, and where its data goes. That leaves supply disruption as the only threat the rule could even claim to address

The FCC’s own evidence shoots down the rule.

The notice cites a DOE assessment saying that even inverters assembled in the United States use chips and power components made almost entirely abroad. So a device can pass this rule while containing the exact foreign components the FCC is worried about, and while sending its data to a foreign server.

The rule allows the exact threats to continue. The chips stay foreign. The data still leaves.

The rule also bans devices that pose no such threat, dropping the U.S. into a worse position. It applies regardless of the nationality of the producer, so an American company that builds inverters in Mexico is banned even if the device never connects to anything foreign.

The legal mechanism is also wrong.

The Secure Networks Act requires a specific determination that particular equipment poses a risk. The FCC used one determination to ban every inverter and every advanced robot made anywhere outside the United States without any particular point at all. That is a categorical ban based on isolationist rhetoric at best, not a specific determination, and the statute does not authorize categorical bans.

The rule extends a reversal of how the Covered List works. The list began with named companies after individual findings against them. Find a flaw, file a report. Everything else was allowed, which is a logical way to handle threats. The flip started with drones in December 2025 and routers in March 2026. Now inverters and robots join the shoot-in-foot list. Everything foreign is banned unless the government grants an exemption, through the Department of War for robots and through the Department of War or DHS for inverters. That’s a transfer of power misaligned with consumer safety. The default moved from allowed to banned for the entire world market, four product categories in seven months

With this default deny list, the exemption process publishes only a checklist. The guidance documents tell applicants what to submit and nothing more. The old equipment authorization system ran through the FCC with public criteria and public procedures. Conditional Approvals run through the discretion of the Department of War and the Department of Homeland Security. The notice states no standard for approval, no deadline for a decision, and no way to appeal a denial.

Finally, the statute this all rests on is a communications law. It was written for telecom network equipment. Inverters and robots qualify only because they contain a thing that connects them to a network, which under this logic makes nearly every modern electronic device a communications device the FCC can ban, with the Department of War deciding which ones come back to market.

There was a straightforward and logical alternative for each threat. If the threat is remote access, the remedy is security requirements on connectivity, software updates, and data flows, applied to every device sold in the US regardless of origin. If the threat is supply disruption, the remedy is component-level sourcing requirements, because the DOE evidence shows the dependence sits in the chips, not the final assembly. That is so obvious, the fact that I have to even write it suggests the American regulator has been completely captured by political corruption. Those simple rules would address the actual threats.