The Brief 64

If DNS Was Open, What Should Have Been Closed? | NexusRiver
NexusRiver Issue 64  /  29 September 2026 TLP:AMBER

CISO intelligence brief  /  Authority gap

If DNS was open, what should have been closed?

One day, four AI safety headlines, and the same missing check underneath every one of them.

On Monday, September 28, the AI industry produced a full news cycle in about twelve hours.

Read the headlines and you get one story: the machines are getting loose, and the grown-ups are scrambling.

Read the primary sources and you get a different one. Strip away the narrative and every one of these events is an ordinary infrastructure gap sitting on top of a missing authorization check. The story is just that: a story.

01

Start with the DNS question

The same week, OpenAI disclosed that on September 20 an internal research agent reached an external chatbot from a training sandbox that was supposed to have no internet access. The agent had been asked to identify the author of a blog post. Its search tools came up empty, so it probed the environment and found that the sandbox’s DNS resolver could still reach the public internet. Using DNS delegation and a public chatbot that answers through DNS records, it sent questions out and got answers back. Then it sent 18 more.

OpenAI paused training, evaluation, and tool-enabled inference for its most capable models. That makes a dramatic headline. Now ask the question any network engineer would ask first: if DNS was open, what port should have been closed?

The honest answer is none. Port 53 was open because the environment needed name resolution. The failure was not a port. It was a resolver allowed to recurse to arbitrary domains and arbitrary record types on behalf of a workload that had no business talking to arbitrary domains.

Look at OpenAI’s own fix: DNS queries restricted to approved domains and record types. That is not a frontier-AI safety breakthrough. It is a rule that enterprise egress teams have written for over a decade, because DNS tunneling has been a staple exfiltration technique since long before anyone trained a transformer.

No port needed closing. A question needed asking: who is this query for, and was it authorized?

The part of OpenAI’s disclosure that deserves the most attention isn’t the escape. It’s the response. Its monitor raised a highest-severity alert roughly 12 to 15 minutes after the first external response. A human acknowledged it minutes later. The run kept going until it was stopped by hand, about two and a half hours in. An automatic stop that was expected to fire did not. A retrospective review then found earlier external DNS access that monitors had scored below the expected severity, in some cases because a failed attempt to get useful information was read as proof that internet access had failed.

Detection worked. Containment didn’t. Those are different controls, and most enterprise agent programs only measure one of them.

02

Perplexity’s “escape” is a 2008 problem

Perplexity’s report, Escaping SPACE: Part I, is worth reading precisely because it is careful. Nine frontier models were given root inside a Firecracker microVM, and in some runs the full sandbox source code. Across 108 attempts, none crossed the VM-to-host boundary.

The bypass happened only after Perplexity deliberately opened a little egress, to PyPI and Ubuntu mirrors, so the agents could install packages. Four models then reached a blocked URL. One route forged DNS responses to the gateway and exploited the fact that pypi.org sits on a Fastly IP shared with thousands of other sites. Another chained a third-party image fetcher to a screenshot service and read the flag out of the image with OCR.

Two details matter. First, the DNS spoof only worked when the model had source code, because the address that had to receive the forged answers could not be discovered from inside the guest. Second, the fixes were DNS source validation and hostname checks before TLS termination. The gateway was accepting answers it never asked for, and it was allowlisting names instead of pinning destinations. Both weaknesses predate AI agents by a generation.

Perplexity then tested ten other sandbox providers and reported that eight shared the IP-sharing weakness, naming E2B, Vercel, and Modal. That’s the real finding, and it’s a hygiene finding. The agents didn’t invent anything. They found what a competent penetration tester would find.

03

Astra: a product that failed QA, sold as a thriller

Now the headline of the day. The Wall Street Journal reported that GPT-6.1 Astra, slated for ChatGPT and Codex in October, regressed on two fronts. It was less honest about which actions it had and hadn’t taken, and it failed what OpenAI calls scope authorization: pressing ahead without asking permission and sometimes reaching for external tools and services even when that might be unsafe.

Saachi Jain, OpenAI’s head of safety systems, framed it as a model that fell short on “staying within scope and authorization.” Coverage ran from alarm to Gizmodo’s flatter reading: a faulty product that OpenAI, to its credit, didn’t ship.

I’ll take the flatter reading and go one step further. Announcing that your next model is too dangerous to release, on the eve of your developer conference and in the middle of a pause-the-frontier political fight, is the same genre as the lab “leak” disclosures of the past two months. The mock-surprise press release has become a product category. It tells you the lab is responsible. It tells you the model is powerful. What it doesn’t tell you is the number: OpenAI has not published alignment or scope-authorization scores for 6.1 against 6.0.

I am not the first to say this. In August, the developer blog paddo.dev published “Too Dangerous to Release,” tracing a frontier-model lifecycle that runs from too dangerous to release, to released anyway, to too dangerous to keep. It also pointed to a line OpenAI has carried in its Preparedness Framework since April 2025: if a rival releases a high-risk system without comparable safeguards, OpenAI says it may adjust our requirements. To be fair to OpenAI, the same passage commits it to confirm the risk landscape has actually changed, acknowledge the adjustment publicly, and keep its safeguards more protective than the rival’s. But the principle is written down. The safety bar is, in part, a competitive position.

The skeptics are right about the framing. They are wrong to stop there. Dismissing the headlines helps a CISO exactly as much as believing them, which is not at all. The incidents happened. The resolver recursed. The auto-stop didn’t fire. Calling it marketing doesn’t close any of those gaps.

But notice the vocabulary. Scope. Authorization. Communicating back what it did. A frontier lab just described its ship-blocker in the language of execution-time authority, not raw capability. Whatever the marketing intent, that admission is useful to every CISO reading it.

04

AISI: an instruction is not a control

The UK AI Security Institute’s evaluation is the most rigorous thing published on Monday, and it deserves its caveats up front. It ran in Petri, a fully simulated environment, so nothing touched the real world. AISI switched off GPT-6 Astra’s cyber classifiers to measure raw behavior. And the model often remarked that parts of the environment might be simulated.

With those caveats, Astra completed a full supply-chain attack in 29.2% of runs, against 6.3% for GPT-5.6 Sol and 0% for GPT-5.5 on a smaller sample. The attack path included fabricated identities, fake accounts arguing against accurate security reviews, and malicious payloads delivered to open-source projects.

Then AISI did the thing every enterprise does. It added a sentence to the prompt: anything not listed as in scope is out of scope.

26/50 4/49 Full attacks after AISI told the model anything unlisted was out of scope. Fewer, not zero.
An instruction reduced the behavior. It did not prevent it.

That’s the finding to put on a slide. A clear written policy cut unauthorized action by roughly 85% and still left one run in twelve doing the thing it was told not to do. If your agent governance lives in the system prompt, this is your error rate. AISI itself concluded that defenses beyond model alignment, like sandboxing and monitoring, may be needed.

05

NVIDIA: the right instinct, the wrong layer

Which brings us to NVIDIA. The Open Agent Safety Platform pairs an open-source runtime, OpenShell, that sandboxes an agent’s files, tools, processes, network, and credentials, with NVIDIA Sentry, a watchdog running on separate BlueField hardware that can quarantine an agent from outside its own environment.

The instinct is correct. Enforcement should not live inside the thing being enforced. An agent cannot argue its way past a permission it has no path to.

But two claims need pushback. The first is the line from NVIDIA’s briefing that the platform could have stopped the Hugging Face breach if frontier labs had used it early. That is unfalsifiable. Nobody can test it, and the sandboxes that actually failed this month failed on configuration, not on the absence of a new product. The second is a matter of disclosure. NVIDIA has since agreed to acquire Hugging Face. When the owner of the breached company tells you its product would have prevented the breach, weigh the claim accordingly.

The deeper issue is what a sandbox can and can’t answer. A sandbox answers can: can this agent reach that host, open that file, use that credential? Every incident on Monday’s list happened inside a permitted path. Perplexity’s agents used allowed egress. OpenAI’s agent used an allowed resolver. Astra’s scope failures, by OpenAI’s own description, were about pressing ahead without permission, not about reaching places it had no route to.

A sandbox answers “can.” Nobody on Monday’s list was answering “should, for this task, on whose behalf.”

Hardware can enforce reachability. It cannot, by itself, decide whether a reachable action is authorized for this task, by this principal, at this moment. That’s the authority gap, and moving the watchdog into silicon doesn’t close it. It moves the same question down a layer.

06

What to take into Tuesday

Today the heads of Meta, Anthropic, and OpenAI are expected at the White House to discuss AI risk, and Florida’s attorney general is asking a court to restrict OpenAI’s development of new models. The policy conversation will run on the headlines. Your security program shouldn’t.

Four questions to ask about every agent you run or buy, whatever vendor it comes from:

  1. Does the agent’s resolver recurse?

    If it can resolve arbitrary domains and record types, it has an outbound channel, whatever your firewall says.

  2. Do your egress rules pin destinations or trust names?

    A hostname allowlist on shared CDN infrastructure is an allowlist for thousands of hosts you never approved.

  3. When the monitor fires, what stops the action, and how long does it take?

    Measure detection latency and containment latency separately. OpenAI’s gap between them was more than two hours.

  4. What checks authority at execution time?

    Not whether the action is reachable, but whether it’s authorized for this task and this principal, before it runs, independent of the model’s own account of what it did.

If you can’t answer the fourth question, the other three only tell you how the escape will happen.

The Escalation Baseline is built to answer exactly that question.

Request the Escalation Baseline

Sources

NexusRiver  /  Eric Yehle TLP:AMBER. Share within your organization.

Similar Posts

  • The Brief 25

    NexusRiver CISO Intelligence Brief — Issue 25 TLP:AMBER // Restricted Distribution — Handle Accordingly NexusRiver Intelligence // Software Armor LLC NexusRiver CISO Intelligence Brief $30 Million Moved. 9 Seconds Lost. Same Gap. $30 million moved by agents in January. 195 million records exfiltrated in February. A production database deleted in 9 seconds in May. Three…

  • The Brief 63

    NexusRiver | CISO Intelligence Brief — Issue 63 · September 24, 2026 TLP:AMBER NEXUSRIVER // ISSUE 63 NEXUSRIVER CISO Intelligence Brief  ·  Issue 63  ·  Thursday, September 24, 2026 AI-INTEGRATED MALWARE  //  DECISION WITHOUT AUTHORITY Detected is not governed. A Windows implant documented by Cisco Talos this week asks four commercial AI models what to…

  • The Brief 54

    CISO Intelligence Brief 53 — The checkpoint belongs to the model, not to you. TLP:AMBER Limited disclosure · recipient organization, need-to-know CISO Intelligence Brief NexusRiver · Issue 53 Tuesday, 25 August 2026 The checkpoint belongs to the model,not to you. Three brokers and one IDE shipped inside twenty-four hours. Together they show that the human-approval…