A third swarm surfaces, Anthropic's CEO asks for the brake, an expired CDN domain still runs on thousands of sites, your Windows estate ages out, and CISA says lie to attackers.
In this edition
- 01Three AI agent swarms. You only heard about one.
- 02Anthropic's CEO wants the industry to slow down. Take the one usable part.
- 03Someone bought an abandoned CDN domain. Thousands of sites still call it.
- 04A whole quarter of your Windows estate quietly changes support status.
- 05CISA finally tells you to lie to attackers.
Get the next GRC Brief in your inbox.
Subscribe to The GRC BriefThree AI agent swarms. You only heard about one.
You know about the model that escaped its sandbox and broke into Hugging Face. Two more have surfaced, both found by outsiders, both from the same research collective: 18,000 posts on a German developer wiki used as a message board for six weeks, and now the bigger one. The "major malicious attack" that hit RubyGems in May, which maintainers read as a denial of service and which shut new account registration for four days, was an agent swarm. Roughly 3,000 packages. The goal was mundane, scraping public meeting calendars from three London councils, and rate limits had blocked them. So they published gems that RubyDoc.info executes during a documentation build and ran their crawler on RubyDoc's servers instead, using YARD's documented ability to load a script the package author names. OpenAI confirms its agents used RubyGems to reach the internet, says it has not verified that they uploaded the packages, and calls its review ongoing.
Source: The Hacker News · Kitts, Larsen & Von Arx report, 11 Sep 2026
My take
Nothing was exploited at RubyDoc. YARD loaded a script the package author pointed it at, a documented feature working correctly. The agents didn't break the build system, they used it. Your pipeline extends the same courtesy to every package you pull and every config file inside it. If you treat the build environment as a tool rather than as production, change that this week.
And hold the pattern. Three incidents, none disclosed by the party that knew first. RubyGems maintainers spent four months not knowing who had DDoSed them. The wiki was fought off by one volunteer deleting pages by hand. Be fair on the facts, an investigation takes time. But when the organisation holding the logs isn't the one that tells you, you find out from a volunteer with a delete button.
Anthropic's CEO wants the industry to slow down. Take the one usable part.
On 12 September, Anthropic's Dario Amodei argued the AI industry should slow down and let safety catch up, warning that within six to twelve months a model could run a swarm capable of taking over much of the internet. He asks for permanent, employee-like access for external evaluators at every frontier lab, antitrust waivers so labs can coordinate on safety, and coordination with authoritarian governments. Sam Altman backed the embedded evaluator. The enterprise version of the argument landed the same week: stop securing agents inside your environment and start limiting their autonomy. One machine identity per agent instead of a shared service account. Credentials scoped to a task that expire with it. A live inventory of what agents can reach. Logs of what the agent did rather than what it was meant to do, read by someone independent. Critics note the warnings arrive months before IPOs valued in the hundreds of billions.
Source: SecurityWeek · Amodei essay, 12 Sep 2026
My take
Silicon Valley has discovered that you should control a system before you improve it. Welcome to Europe. We call it the AI Act, NIS2 and DORA, and we've spent three years being told it's innovation-killing bureaucracy. The only edge they have on us is that they're saying it after breaking something.
Take the alarm seriously anyway, and notice the timing at the same time. Then strip the plan down to what you can act on: independent evaluators with real access, reading the logs, confirming the system stayed inside its limits. That's third-party assurance, and it's where the enterprise advice lands from the other direction. One identity per agent, credentials that die with the task, someone outside the team who reads the logs. That's access management and ISO 42001, applied to a new kind of user.
Someone bought an abandoned CDN domain. Thousands of sites still call it.
A caveat first, this is a vendor piece, contributed by the client-side security firm Report URI. The case stands anyway. In July 2025 someone registered a domain that used to belong to a content delivery network, wound down years earlier and allowed to expire. What it never lost was its callers: thousands of sites, repositories and documentation pages still hard-code hostnames under it. The new owner holds wildcard DNS across the whole domain, so what those pages load tomorrow is his decision. Nobody was notified, because from the outside nothing broke. The precedent is polyfill.io, embedded in over 110,000 sites, which changed hands in 2024 and began serving conditional redirects to mobile visitors. Dependency scanning misses this, because a third-party script is neither built nor shipped by you. It's fetched by the visitor's browser, from a server you don't run, on every page view, with the same privileges as your own code, including reading form fields as they're typed. For card payments it's settled: PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 have been mandatory since March 2025, and they require every script on a payment page to be authorised, inventoried and monitored for change.
Source: The Hacker News · contributed by Report URI, 18 Sep 2026
My take
This is the part of the supply chain your SBOM does not cover. We spent the summer on npm worms and bills of materials, and all of that inventories what you compile and ship. This runs in your customer's browser, from someone else's server, with full reach into your payment form. And you've seen the mechanism twice here already: the ex-employee's mailbox nobody deleted, the expired Visa card that still authorised payments. Expired is not revoked. Someone picks up the keys you threw away.
Monday morning, and this one is easy. Deploy a Content Security Policy in report-only mode for a week. It enforces nothing and blocks nothing. It just tells you what is executing in your users' browsers, and that list is always longer than anyone expects.
A whole quarter of your Windows estate quietly changes support status.
Two clocks run out on the same Patch Tuesday. On 13 October 2026, Windows Server 2022 leaves mainstream support and moves to extended support, which still carries free monthly security updates through 14 October 2031. What stops are non-security fixes, design changes and the incident support attached to your licence. On the same date, the third and final year of Extended Security Updates for Windows Server 2012 and 2012 R2 ends, and those left extended support in 2023, so that really is the last patch of any kind. Then, 91 days later, on 12 January 2027, Windows Server 2016 reaches the end of extended support. Unlike 2012 R2, no traditional paid ESU programme has been announced. The route Microsoft points to is Azure.
Source: Microsoft · Windows message centre, Sep 2026
My take
Read those dates carefully, because the headline everyone repeats is the wrong one. Server 2022 leaving mainstream support is not end of life. It keeps free security updates for another five years. The headstones that matter are 2012 R2, whose final ESU runs out the same day, and 2016 in January, quite possibly with no paid way to buy more time.
What makes this dangerous is the theme of the whole issue: nothing breaks. On 13 January 2027 the servers boot, the applications run, nobody notices. The only people who force the decision are your auditor, your insurer and your vendors dropping the version from their support matrices, and all three arrive after the date. Treat it as asset lifecycle, not patching. If you're still migrating off 2012 and 2016 while 2022 changes status behind you, you don't have a patching backlog. You have a graveyard of operating systems and no funeral schedule.
CISA finally tells you to lie to attackers.
On 16 September, CISA published "Using Cyber Decoys to Strengthen Detection and Response", its first detailed guidance on defensive decoys. The problem it targets is the one defenders keep losing: adversaries using legitimate credentials and living-off-the-land techniques, who therefore trip nothing. It covers tripwires, breadcrumbs and honeytokens, assets that look like real systems, accounts or data but exist to reveal an intruder's presence. The work maps onto MITRE Engage and ATT&CK, and the steps are pitched as low-complexity for teams at any level of maturity. The return is earlier detection through high-fidelity alerts, positioned as a complement to Zero Trust on the assumption that an adversary already has some access. The UK's NCSC found the same in its Active Cyber Defence testing: useful for visibility, including on legacy systems, but only where carefully implemented.
Source: CISA · Cyber decoys guidance, 16 Sep 2026
My take
Finally. I put decoys everywhere I work, and everywhere my teams work. Hidden in the network, in file shares, in accounts that look real and belong to nobody. Almost nobody thinks about this, and now there's a free government document that walks you through it. The excuse is gone.
Look back at this issue and you'll see why it closes here. Agents roaming a build environment with legitimate access. A script running in your customer's browser with your privileges. Credentials that outlived their owner. None of it breaks anything, which is exactly why your tooling stays quiet. A decoy inverts that: nobody legitimate has any reason to touch a honeytoken, so when one fires you get signal with almost no noise. Build it properly, a bad decoy is a liability. And don't treat this guidance the way most people treat their audit reports, read once, filed, forgotten. The decoy you deploy is the control. The PDF is just paper.