Can You Stop Your AI Agent? New US Guidance Puts Control to the Test

When an Agent Acts Without Instructions

If an AI agent takes an action nobody instructed it to take, can its operator stop it and preserve the evidence? New US guidance puts that practical question ahead of promises about safe behaviour.

Our main story today is the incident-response guidance published on 16 October by NIST, the US National Security Agency and CISA. It asks how organisations training and evaluating powerful AI agents can retain control when those agents do something significant outside their instructions.

The agencies have published ten practices. They're voluntary, aimed primarily at organisations training or evaluating highly capable agents, although some may also apply to organisations deploying them. That scope is important. This is a reference for handling unexpected agent activity, not a new legal requirement for every business using a chatbot.

Several recommendations are concrete. Restrict network access. Keep monitoring systems and logs outside the agent's ability to tamper with them. Preserve evidence when an incident happens, and verify that containment has been restored before allowing the agent to resume.

The protected monitoring recommendation is especially useful. A log can only help an investigator reconstruct an incident if the record remains trustworthy. If the system under investigation can alter the record of its own actions, the operator has a second problem: uncertainty about what evidence is missing. Keeping that record beyond the agent's reach separates the activity being watched from the means of watching it.

Network restrictions address a different part of the problem: the scope of what an agent can reach. In practical terms, limiting access gives an operator a more defined environment to investigate. It doesn't prove that an agent will behave as intended inside that environment. It does make the boundary an explicit part of the design, rather than something discovered after an unexpected action.

Then there's the restart decision. The guidance calls for checking that containment has been restored before activity resumes. Stopping a run and establishing that it's safe to restart are different judgments. An interruption may end the immediate activity without explaining what allowed it, or whether the same conditions remain. Evidence preservation gives the investigation something to work from before that decision is made.

For an organisation evaluating autonomous systems, these practices offer a way to make a review much more specific. Where does the record of an agent's actions live? Can that agent change it? What evidence survives when a run is stopped? Those questions turn a broad assurance about oversight into things an operator can examine.

I'd put the emphasis on the ability to investigate. A useful evaluation doesn't only ask whether the agent completed its assigned task. It also needs enough independent evidence to understand significant actions that weren't assigned. Otherwise, an impressive result and an unexplained incident can arrive together, with no reliable way to separate them.

There are limits to what this publication establishes. The agencies haven't demonstrated that these controls eliminate agent-control failures. Their implementation and effectiveness still need testing. Nor does the publication itself tell us how often the incidents it addresses are occurring.

My takeaway for organisations is that containment and recovery can now be assessed against a concrete shared reference. The useful next investment may be less about adding another statement of intended behaviour and more about ensuring the operator can see what happened, retain the evidence and make a justified restart decision. An agent's capability is only part of the operational question; the organisation also needs a dependable way to interrupt its work.

The FTC Asks for Safety Records

That closes the operational question; the shorter news starts with what companies can substantiate about their safeguards.

The US Federal Trade Commission sent civil subpoenas to OpenAI and Anthropic on 14 October, seeking records about AI safety incidents. Reporting published on 15 October includes agency confirmation from CBS.

Reuters, citing Axios, reports that the demands cover security incidents, safeguards, marketing materials and privacy policies. OpenAI told Reuters it would engage constructively with the FTC. The inquiry has therefore moved into a concrete evidence-gathering step, with demands for records from the companies.

Keep the distinction between those layers of reporting in mind. The agency confirmation supports the existence of the subpoenas. The more detailed description of what they're seeking comes through Axios's unnamed source, as reported by Reuters. The full text of the demands wasn't available in the verified reporting, so we don't have a complete account of their scope.

A subpoena also doesn't settle the underlying questions. The investigation's outcome is unknown. We can't take the demand for evidence and turn it into a finding that either company has broken the law, or assume what response the agency may ultimately pursue.

What makes the reported scope consequential is the inclusion of both operational records and material presented to users. Security incidents describe what happened. Safeguards describe the protections around the product. Marketing and privacy policies describe what a customer was told to expect. Looking across those categories could expose gaps that aren't visible when each is considered separately. That's an interpretation of the reported inquiry, not a conclusion about either company's conduct.

For organisations buying AI services, my read is that safety representations are becoming a more tangible commercial issue. A confident description of a safeguard has limited value if a supplier can't explain its operation or support it with records. The FTC inquiry doesn't answer which products are safer. It does sharpen the distinction between a claim a customer can read and evidence that a company can produce when that claim is examined.

Meta's Download Comes With Hardware Questions

For developers who want more control over where a model runs, there's a substantial new download to consider.

Meta released Muse Spark Open on 15 October, making the model available as downloadable weights and through hosted inference partners. It's a multimodal model for coding and agent workflows, so developers now have a self-hostable option as well as a route through a service provider.

The scale is significant: 816 billion total parameters, with 42 billion active, and a context window of one million tokens. Parameters are the learned values in a model; the active count describes the portion used during processing. The lower active figure doesn't mean the full model has become small enough for an ordinary laptop.

Meta's highlighted desktop configuration uses two M5 Ultra Mac Studios, each with up to 512 gigabytes of unified memory. That's a substantial hardware arrangement. Calling it a desktop deployment describes the form of the machines, not an everyday level of affordability or availability.

There's also a distinction between being able to download weights and being able to use them under any business model. The Muse licence requires a separate agreement for model-as-a-service businesses with more than twenty million US dollars in aggregate annual revenue. That provision excludes internal use and ordinary product features.

So the relevant question for a business is what it's providing with the model. Running it internally and selling access to the model itself aren't treated identically by that condition. The threshold alone doesn't tell the whole licensing story; the kind of use matters too.

Meta's performance and safety assessments remain company claims, and the announcement says a full evaluation report is still forthcoming. Availability gives developers something they can assess for themselves, but it doesn't independently establish how well the model will perform in their particular coding or agent workflow.

I see the practical gain here as deployment choice. Developers can consider running the model in an environment they control, rather than being limited to hosted access. Whether that choice is useful depends on the memory they can provide and the licence terms that apply to their service. The highlighted desktop configuration makes that a substantial infrastructure decision, even before evaluating how well the model handles the intended work.

Nvidia Offers Two Agent Model Sizes

Staying with downloadable models, Nvidia offers a different set of trade-offs around size and the work being processed.

Its 14 October technical release introduces Nemotron 3.5 Super and Lightning, along with inference and training resources. Inference is the stage where a trained model processes a request, so those resources are relevant to organisations planning to serve the models themselves.

Super has 120 billion total parameters, with 12 billion active, and supports text, images and video. Lightning is a text model with 30 billion total parameters and three billion active. Both are trained for context lengths of up to one million tokens. That context length describes how much material they can work with at once, rather than a guarantee about the quality of every answer drawn from it.

The two options give developers a concrete starting distinction. A service that needs image or video input has a reason to examine Super. A text-only workload can consider Lightning without treating multimodal support as an automatic advantage. The smaller parameter count is relevant, but it doesn't by itself settle the cost or quality comparison.

Nvidia has released BF16 and NVFP4 checkpoints. These are different numerical formats for the model's stored values, and the release gives organisations deployment resources to evaluate alongside them. The package therefore includes more than a model announcement: developers have downloadable material and serving guidance to work with.

The performance figures still need careful interpretation. Nvidia's published throughput gains are its own measurements under specified serving conditions. Throughput describes how much work a system processes over time. It doesn't establish equivalent savings on different hardware, with different numbers of simultaneous requests, or on a different task.

For a developer choosing an agent model, I'd translate the efficiency claim into the cost of completing the actual workload. A faster serving result is useful only in the context of the output the service needs. The release supplies new candidates and recipes for making that assessment; it doesn't supply a universal cost answer.

That leaves a sensible dividing line for evaluation: choose the required inputs first, then examine how the candidate behaves on the hardware and request pattern the service will actually use.

Cloudflare Adds Code to the Gateway

There's a separate change for the people responsible for controlling what crosses an organisation's network boundary.

On 15 October, Cloudflare introduced a Gateway Forward action that passes matched HTTP traffic to Workers, its platform for running customer-written code. Forward is in public beta and lets that code inspect or modify requests and responses.

That creates room for organisation-specific handling inside the traffic path. Rather than operating a separate proxy for a specialised transformation, an administrator can send matching traffic to code running on Workers. The change is about where that logic can live and how it can be connected to Gateway's traffic handling.

Cloudflare has also made custom validation functions available for data-loss prevention, usually shortened to DLP. DLP is used to identify sensitive information in traffic. Validation functions let customers add their own logic to assess a detection, giving them a way to account for details that a general detection rule may not capture.

There are three availability states to keep straight. Forward is a public beta. DLP validation functions are available now. The separately named Gateway Custom Functions are planned for before the end of 2026. That third feature hasn't arrived simply because the other two have been announced alongside it.

The operational trade-off is fairly direct. Worker requests incur standard Workers billing, and the customer's code adds its own execution time. A piece of traffic-handling logic may remove the need for a separate proxy, but its processing still has a cost and takes time. The announcement doesn't establish what either will be for a particular organisation.

My judgment is that this could simplify specialised security infrastructure, while making the quality of customer-written code more consequential. Code that changes a request or response participates directly in the organisation's security boundary. Its correctness becomes part of the protection the administrator is relying on.

For an organisation with a specific traffic transformation to implement, the useful comparison is therefore the complete arrangement: the proxy it might no longer need, the Worker it would run instead, and the time and billing that code introduces. Forward's beta status also belongs in that decision, particularly where the traffic handling is important to an existing service.

An Exploited Windows Flaw Has a Fix

A more immediate item for Windows administrators: this security release includes a fix for an attack route already being used.

NHS England's advisory dated 14 October urges affected organisations to apply Microsoft's October security updates. It highlights a Windows Shell vulnerability identified as CVE-2026-96951. Microsoft reports detected exploitation, and the advisory records the flaw's addition to CISA's Known Exploited Vulnerabilities catalogue.

The release addresses 1,413 vulnerabilities across Microsoft products. That's a striking total, but it isn't the most useful detail for deciding what needs attention first. Confirmed exploitation gives administrators a concrete reason to prioritise affected systems.

Two other flaws highlighted by the advisory were publicly disclosed. They weren't reported as actively exploited in that advisory. Public disclosure and detected exploitation are different signals, and combining them would overstate what's known about attacks.

We also don't have evidence here establishing how widespread exploitation of the Windows Shell flaw is. The supported conclusion is narrower and actionable: exploitation has been detected, and a fix has been released.

For organisations working through the update, I'd give that observed attack route more weight than the size of the overall vulnerability count. The count describes the release's breadth. Exploitation status helps establish urgency for the systems that are actually affected.

Willow Improves a Quantum Building Block

At a very different stage of practical use, Google has reported progress on making quantum operations more reliable.

On 15 October, Google announced a hardware demonstration of magic-state cultivation on its Willow quantum processor, accompanying publication in Science. Magic states are specially prepared quantum states used in error-corrected computing. The work targets the resources needed to prepare those useful states reliably.

Google reports roughly forty-fold fewer errors in the prepared states and logical T-state fidelity of 99.99 per cent. Fidelity describes how closely the prepared state matches the intended one. These measurements concern that component of the computation, not the accuracy of an entire quantum calculation.

That's an important boundary around an impressive number. It would be a mistake to turn 99.99 per cent state fidelity into a claim that a complete quantum computer now delivers answers at that accuracy. The researchers explicitly say larger-scale demonstrations and further technical work are still needed.

These are Google's reported measurements. There's no established timetable for practical large-scale use, and this isn't a newly available general-purpose service.

For organisations following quantum research, I'd watch the resource burden of reliable operations alongside raw qubit counts. If a method can reduce that burden as it scales, it could make useful error-corrected computing easier to build. This demonstration advances that question without resolving the remaining engineering work.

What Changes for You

If you've been looking for an image model you can run yourself, there's a new option with some very specific limits.

Black Forest Labs released FLUX 3 Image Klein on 15 October as downloadable weights and a paid API. It supports image generation, editing and compositions using up to ten reference images. Working AI builders can now consider integrating it locally or using the hosted API.

The hardware claim needs unpacking before anyone treats it as a simple eight-gigabyte download-and-run proposition. Black Forest Labs advertises an optimised INT8 setup running on graphics cards with eight gigabytes of video memory. INT8 refers to an eight-bit numerical representation. That figure belongs to the optimised setup, not every way of running the model.

The published reference implementation instead reports 25 to 31 gigabytes at 1,024 by 1,024 resolution, with prompt expansion disabled. These are different configurations. Compatible software and the memory needed by the whole pipeline remain part of local deployment, and the eight-gigabyte claim hasn't been independently benchmarked here.

There's an editing limitation worth knowing too. The model card says edits can change content outside the requested region. Bounding boxes guide placement; they don't enforce a hard mask. If preserving everything outside a selected area is essential to your application, that behaviour affects whether the model is suitable.

Commercial permission is also conditional. The licence allows qualifying users below five million US dollars in gross annualised revenue, including affiliates, to generate commercial outputs under its terms. That isn't blanket permission for commercial fine-tuning or redistribution.

For builders, the useful change is a choice between a self-hosted image workflow and paid API access, with generation and editing in the same offering. I'd assess local feasibility using the complete software and memory configuration, not the smallest advertised figure. And for an editing product, the decisive limitation may be whether an unrequested change elsewhere in the picture is acceptable at all.