Menu
Programmer typing code on a laptop, illustrating AI agent security controls.

AI Tests Reached Real Systems, Plus 2 Stories

, , , , , ,

Anthropic’s models reached live systems, but they didn’t break out

The headline version says Anthropic’s AI models escaped their sandboxes. That isn’t quite what the evidence says, and the correction is more useful. According to Anthropic’s new IPO filing, four models in cybersecurity tests reached live systems for periods ranging from 10 to 34 hours. In one case, a model found a stored password, gained administrator access, collected more credentials, changed settings and reached personal data.

That sounds like a model defeating a carefully built containment system. Anthropic’s own incident report describes a more ordinary failure with a less cinematic name: the test environment was misconfigured. The prompt told the model it was in a simulation with no internet access, but a misunderstanding with a testing partner left the internet connection open. Some standard monitoring and safety controls were also disabled for the evaluation. A sentence in a prompt is not a firewall, any more than a sticky note saying “do not enter” is a locked door.

The models used basic techniques rather than a new exploit, and Anthropic says it found no evidence that they coordinated, deliberately tried to escape or copied themselves elsewhere. Still, one older model kept working after it encountered evidence that the systems might be real. Anthropic paused some evaluations, notified affected parties and, the filing says, paused training of its next frontier model for more than a month while it strengthened protections against theft of model weights and other intellectual property.

The filing matters because it replaces a hypothetical debate with operating evidence. A capable agent didn’t need a science-fiction rebellion. It needed reachable systems, usable credentials and enough time to keep trying. Those are familiar security failures, now attached to software that can act at machine speed.

For ordinary ChatGPT or Claude users, there isn’t an emergency setting to change today. The business lesson is different. AI agent security controls have to exist outside the model: restrict outbound network access, use short-lived credentials, keep production secrets out of test environments, log tool calls and give a named human the ability to stop a run. The question isn’t whether the agent was instructed to stay inside. It’s what the surrounding system actually allowed it to do. That is also the control problem behind last week’s AI-agent hacking campaign.

Turning on AI is the easy part

Deciding what an AI tool should be allowed to see, who should use it, what work it should perform, and what happens when it gets something wrong is the more interesting problem. Raymond Tec helps businesses connect and automate the tools they actually use without treating every new feature like a button that obviously needs to be switched on.

Weak certificate keys passed two audits

Website certificates work because browsers trust a chain of cryptographic signatures. A certificate authority sits near the top of that chain and vouches that a site’s certificate belongs to the site named in it. If the authority protects that signing key badly, an attacker may be able to create convincing fakes. This is infrastructure most people never see, right up until a browser replaces the website with a large red warning.

Indian certificate authority eMudhra said it is leaving the global public certificate business after weak keys were found in six intermediate authorities. The keys were generated in April 2025 and went unnoticed for about 18 months, including through two audits. Chrome’s root program says it blocked the affected intermediates on October 17 within roughly two hours of receiving the report, then moved to remove the upstream eMudhra root from its trust store.

There is an important limit to the scary version of this story. Chrome says no certificates chaining to those intermediates had appeared in public Certificate Transparency logs before the block, so no fraudulent certificate from them could have been trusted by default in Chrome and other browsers that enforce those logs. eMudhra also says its infrastructure wasn’t breached. The failure is still serious because key strength is one of the first things a certificate audit is supposed to catch.

Most readers don’t need to replace anything. Website owners should check the certificate chain if their provider contacts them, their site uses an eMudhra or emSign certificate, or browsers begin showing warnings. Replace an affected certificate through a trusted provider and test the full chain, including on older devices. Visitors should update their browsers and resist the very human urge to click through a certificate warning just to make it go away.

This is also a reminder that compliance evidence and technical evidence aren’t the same thing. An audit can verify that a process exists. It can’t make a weak cryptographic key strong, and it doesn’t excuse an 18-month delay in finding one.

Business IT goes well beyond the website

Your business also depends on workstations, cloud accounts, browsers, Wi-Fi, remote access, collaboration tools, and all the other technology that quietly becomes infrastructure. Raymond Tec works across that whole stack, whether the problem lives on a server, on a desk, or somewhere in between.

Node.js fixes a Brotli memory-safety flaw

Node.js has released security updates for a high-severity flaw in its Brotli decompression code. Brotli is the compression format behind plenty of smaller web responses. A specially malformed input can make the decoder write beyond an eight-byte buffer, which can crash the process, expose memory or, in the worst case, let an attacker run code.

The affected supported branches are Node.js 22.x, 24.x and 26.x. Fixed versions are 22.23.4, 24.22.1 and 26.12.1. The Node.js project warns that end-of-life releases should be treated as affected too, but they won’t receive a patch. If an application accepts attacker-controlled data and decompresses it through node:zlib, directly or through a dependency, this should move near the top of the update list.

That qualification matters. A Node application isn’t automatically remotely exploitable just because Node is installed. The vulnerable path has to process untrusted Brotli data. But waiting to prove exploitability one application at a time is usually a poor bargain when supported fixes are available. Inventory the runtime version, update it, restart the service and run the application’s normal tests. If the app is on an unsupported Node branch, migration is the security fix. “We’ll patch it later” isn’t a branch of Node.

For a small business, the practical owner may be a developer, a managed provider or the vendor behind a hosted product. Someone should be able to name that owner. Otherwise a fix can be publicly available while everybody assumes somebody else installed it.

Still in a reading mood? The Raymond Tec News archive covers security, AI, small-business technology, policy, and the places technology collides with ordinary life — without requiring a computer-science degree to get through it.

Sources / Further Reading

Photo by Mario Amé on Pexels.

Related Posts

Leave a Reply

Only people in my network can comment.