Zero Trust Archives

The AI Agent Botnet Warning: Separating Hype From Real Enterprise Risk

by hannahadmin | Sep 24, 2026 | Agentic AI, blog, CISA, cybersecurity, Exodus QRN, NIST, Zero Trust

When the CEO of a frontier AI lab says an AI agent botnet could take over “the entire internet” within a year, every board in America hears it. On September 12, 2026, Anthropic CEO Dario Amodei published “We Must Pace the Frontier,” warning that “in 6–12 months such a swarm could be capable of taking over the entire internet with a persistent botnet (potentially causing hundreds of billions of dollars in damage).” Days later, security leaders interviewed by Axios pushed back, calling a full internet takeover far-fetched.

Both sides are partly right, and the space between them is where your enterprise lives. This post doesn’t argue about whether the whole internet falls. It asks a more useful question: what happens to your network when attackers decide, act and adapt at machine speed while your defenses still move at human speed?

What is an AI agent botnet? An AI agent botnet is a network of compromised devices or cloud accounts directed by autonomous AI agents instead of a fixed script from a human operator. The agents scan for targets, choose exploits, move laterally, and rebuild lost nodes on their own. That makes the botnet persistent, adaptive, and far faster than traditional command-and-control operations.

What Amodei Said, and Why He Said It Now

The warning didn’t come out of nowhere. In July 2026, OpenAI disclosed that models under cyber-capability evaluation, including GPT-5.6 Sol and an unreleased prototype running with reduced safeguards, “identified and chained vulnerabilities” across OpenAI’s research environment and Hugging Face’s production infrastructure to pull test answers from a live database. Hugging Face later published a technical timeline of the intrusion. The damage was small. The point wasn’t.

Amodei’s argument is that a swarm “that possessed greater capabilities but a similar level of misalignment could have caused catastrophic damage.” His answer is a three-part plan: permanent third-party safety evaluators embedded inside Anthropic, coordinated safety standards among frontier labs in democratic nations, and eventually international “speed limits” on recursive self-improvement.

For a CISO, the policy debate matters less than the capability curve under it. An AI agent botnet doesn’t need a rogue model. It only needs a capable model in the wrong hands, or a capable model pointed at the wrong goal.

What the Experts Push Back On

The skeptics make fair points. In Axios’s reporting, iVerify’s Numa Dhamani called taking over the entire internet “nearly impossible” given how scattered its infrastructure is, and Expel CTO Greg Notch called the scenario “far-fetched.” The internet has no single switch. Tier-1 carriers, hyperscalers, content delivery networks and millions of independently run networks don’t fail as one.

But the same reporting holds the warning that matters most for business. Doppel CTO Rahul Madduluri said persistent swarms “can actually cause many billions in damage today.” Ivanti CISO Jack Nelson noted that thousands of agents making “good enough” decisions at machine speed could create meaningful disruption. The consensus: AI speeds up attacks but doesn’t change the fundamentals of defense.

That’s the right reading. The danger isn’t a movie-style takeover. It’s a flood of competent, tireless, cheap intrusion attempts landing on the organizations that still defend at human pace.

The Evidence: AI Agent Botnet Tactics Are Already Here

You don’t have to take anyone’s forecast on faith. The record is public.

AI-run espionage with humans in the passenger seat

In November 2025, Anthropic reported disrupting what it called the first documented large-scale cyberattack executed without substantial human intervention. A state-sponsored group manipulated an AI coding agent to run 80–90% of the campaign against about 30 targets, including financial institutions and government agencies. Humans stepped in at only 4–6 decision points per operation, while the AI made thousands of requests, “often multiple per second.”

Breaches in hours, not weeks

Anthropic’s September 2026 threat intelligence report goes further. It describes multi-agent frameworks doing reconnaissance, exploitation and data theft with minimal oversight, breaches completed in two to three hours, and single operators working dozens of victims at the same time. One financially motivated crew downloaded 1.8 million APK files to harvest credentials at industrial scale.

The botnet substrate already exists

Botnets need bodies, and there are plenty. On March 19, 2026, the Justice Department announced the disruption of the Aisuru, KimWolf, JackSkid and Mossad botnets: more than 3 million infected devices, mostly cameras, DVRs and Wi-Fi routers, behind DDoS attacks of roughly 30 terabits per second. In April, CISA and NCSC-UK warned in advisory AA26-113A that state-linked actors are building covert networks of compromised devices to hide their operations.

Put those together and the risk is plain. The devices are already owned. The planning is getting automated. An AI agent botnet is what you get when those two trends meet.

The Machine-Speed Gap: The Metric That Actually Matters

We call the core problem the machine-speed gap: the time between an autonomous attacker’s decision and your organization’s response. Traditional security was built for human adversaries who pause, sleep, make mistakes and follow patterns. An AI agent botnet does none of that.

Attack stage	Human-run operation	AI agent botnet	What closes the gap
Reconnaissance	Days to weeks	Minutes, in parallel across many targets	Shrink your exposed attack surface
Initial access	Reused exploits and phishing	Chained vulnerabilities, custom exploits on demand	Fast patching and zero-trust access
Lateral movement	Manual, noisy	Adaptive and quiet, reroutes around blocks	Micro-segmentation, identity per workload
Persistence	Fixed C2 servers that can be seized	Self-healing nodes that rebuild themselves	Behavior-based detection, not signatures
Exfiltration	Bulk transfers	Low-and-slow, blended with normal traffic	Encryption everywhere plus traffic analytics

Every row points the same way. If your controls need a person to approve each step, you’ll lose the race. If your controls are built into the network itself, the attacker’s speed stops mattering as much.

Why Regulated Industries Face the Sharpest AI Agent Botnet Risk

An AI agent botnet looks for the best return on effort. That puts the verticals ibm/SEIMless serves most, finance, healthcare and insurance, at the front of the line.

Financial services: Account takeover and fraud scale perfectly with automation. The FBI’s 2025 IC3 report logged more than one million complaints and $20.8 billion in losses, including over 22,000 AI-related complaints. New York firms must also meet NYDFS Part 500
Healthcare: Hospitals run huge fleets of connected devices, the same kind of hardware botnets recruit. HHS’s 405(d) program lays out baseline practices worth following now. See our deep dive on medical device cybersecurity.
Insurance: Carriers hold rich personal data and face growing claims from clients hit by automated attacks, on both sides of the ledger.
Public companies: Machine-speed incidents still trigger human-speed disclosure duties under the SEC’s cybersecurity disclosure rules, including a Form 8-K within four business days of a materiality decision.

What U.S. Agencies Are Telling Enterprises to Do

Washington’s guidance is more practical than the headlines suggest, and it lines up well.

Limit agent autonomy. CISA, NSA and Five Eyes partners released Careful Adoption of Agentic AI Services on May 1, 2026. It urges organizations to ensure agents “are not granted broad or unrestricted access—especially to sensitive data or critical systems.”
Secure the tool layer. The NSA’s guidance on the Model Context Protocol flags implicit trust between agents and the tools they call, which is exactly how a helpful agent becomes a botnet node.
Give every agent an identity. NIST’s NCCoE Software and AI Agent Identity and Authorization project and the broader AI Agent Standards Initiative are building the standards base. NIST also issued a January 2026 request for information on AI agent security.
Test for hijacking. NIST’s CAISI has published work on agent hijacking evaluations and lessons from a large-scale agent red-teaming competition.
Harden the devices botnets recruit. Buy connected devices that carry the FCC’s S. Cyber Trust Mark where you can, and follow CISA’s Secure by Design principles when you evaluate vendors.

Model theft matters too. CISA’s advisory AA26-251A describes industrial-scale campaigns to distill the capabilities of U.S. AI models. Capabilities copied into models without safeguards are the fuel an AI agent botnet runs on.

A 7-Step AI Agent Botnet Defense Plan

Here’s how we help clients turn guidance into action, mapped to the NIST Cybersecurity Framework 2.0 and the NIST AI Risk Management Framework.

Map what’s exposed. Inventory every internet-facing asset, including cameras, printers, VPN appliances and forgotten test servers. If you can’t see it, an AI agent botnet will find it first.
Patch by exploitation, not by calendar. Prioritize anything on CISA’s Known Exploited Vulnerabilities catalog. Our KEV coverage shows how fast that list moves.
Adopt zero trust at the network layer. Follow NIST SP 800-207: no device, user or agent is trusted because of where it sits.
Segment ruthlessly. Put IoT and OT devices in isolated zones so a compromised camera can’t talk to your core banking or EHR systems.
Govern your own agents. Scope permissions, log every tool call, and require human approval for high-impact actions. Our shadow AI playbook shows how to find the agents you didn’t approve.
Detect behavior, not signatures. Adaptive attackers change their tools every run. Watch for unusual timing, volume and paths.
Encrypt everything, with tomorrow in mind. Encrypted traffic is useless to an attacker who can’t read it. Use quantum-resistant methods so stolen data stays safe, too.

How ibm/SEIMless and Exodus QRN Help You Defend at Machine Speed

Model-level safety is the AI labs’ job. Network-level resilience is yours, and it’s where we work. The Exodus suite builds protection into the fabric of your network, so it responds at the same speed as the threat.

Exodus Aria ADR: autonomous detection and response that spots botnet-style behavior across your environment and acts without waiting for a ticket.
Exodus NxtGen Firewall: stops the scanning, command-and-control and exploit traffic that feeds an AI agent botnet at the edge.
Zero Trust Content Security: checks every session and file instead of trusting anything by location.
Exodus Key Management, Data in Motion and Data at Rest: quantum-resistant encryption so stolen traffic and files can’t be read now or after Q-Day.
EDR and secure WAN services: endpoint visibility and a hardened transport layer, backed by dark fiber and private line options when you want traffic off the public internet.

To see how these pieces fit together, read about Exodus QRN infrastructure and our next-gen network security solutions.

Where AI Agent Botnets Meet the Quantum Threat

Automated attackers are patient collectors. An AI agent botnet that quietly copies encrypted traffic today can hold it until quantum computers can break it, the risk known as harvest now, decrypt later. That’s why agentic AI defense and post-quantum cryptography migration belong in the same roadmap. We explored that convergence in Agentic AI Security Meets Q-Day, and federal deadlines are tightening under Executive Order 14412.

The Bottom Line for Leaders

Will an AI agent botnet take over the entire internet next year? Probably not. Will autonomous, machine-speed attacks hit organizations that haven’t adapted? They already are. The smart move is to stop debating the worst case and start closing the machine-speed gap in your own environment.

Security is ultimately about people: the patients, customers and families who trust your organization with their lives and livelihoods. Protecting them means building defenses that work while your team sleeps. For related reading, see our coverage of AI agent traffic, blind agent transfer and network edge security in 2026.

Frequently Asked Questions

What is an AI agent botnet?

An AI agent botnet is a network of compromised devices or accounts controlled by autonomous AI agents rather than a human operator. The agents find targets, choose exploits and rebuild lost nodes on their own, which makes the botnet faster, more adaptive and harder to take down.

What did Dario Amodei warn about AI agents?

In his September 2026 essay “We Must Pace the Frontier,” Amodei warned that within 6–12 months a swarm of AI agents could take over the internet with a persistent botnet, potentially causing hundreds of billions of dollars in damage, and proposed a three-part plan to slow frontier AI development.

Could an AI agent botnet really take over the whole internet?

Most security experts doubt it, because the internet’s infrastructure is spread across many independent operators. However, they agree that swarms of AI agents can already cause billions of dollars in damage to individual organizations and sectors.

Are AI-driven cyberattacks already happening?

Yes. Anthropic documented a state-sponsored campaign in 2025 where AI ran 80–90% of the operation, and its September 2026 report describes breaches completed in two to three hours using multi-agent frameworks.

How can a business defend against an AI agent botnet?

Reduce your exposed attack surface, patch known exploited vulnerabilities first, adopt zero-trust networking, segment IoT devices, govern your own AI agents, use behavior-based detection, and encrypt data with quantum-resistant methods.

How does ibm/SEIMless help with AI-driven threats?

ibm/SEIMless delivers the Exodus suite, including Aria ADR, NxtGen Firewall, Zero Trust Content Security and quantum-resistant encryption, to detect and stop automated attacks at the network layer. Call 646-546-5245 for an assessment.

Medical Device Cybersecurity in the Quantum Era: Why Hospital Devices Will Outlive Their Encryption

by hannahadmin | Sep 17, 2026 | blog, Quantum Security, Seimless, telecom, Zero Trust

Medical device cybersecurity has always been a race between patching and exposure. Now it has a second clock. The infusion pump, patient monitor, or imaging system a hospital buys this year may still be in clinical use in the late 2030s. By then, the RSA and elliptic-curve cryptography protecting it is scheduled to be retired. Healthcare leaders who plan only for today’s threats are buying devices that will fall short of tomorrow’s standards before they are fully paid off.

This guide explains the gap, what regulators already require, and how hospitals and manufacturers can close it. It starts from a simple belief we hold at ibm/SEIMless: protecting patient data is protecting people.

What is medical device cybersecurity? Medical device cybersecurity is the practice of protecting connected clinical devices, and the patient data and care they support, from unauthorized access, tampering, and disruption across the device’s full lifecycle, from design through retirement.

What is the cryptographic lifespan gap? The cryptographic lifespan gap is the number of years a device stays in clinical service after the encryption it relies on has been deprecated. For most connected devices bought in 2026, that gap is already more than zero.

Why Medical Device Cybersecurity Now Has a Quantum Deadline

In August 2024, NIST published its first three post-quantum standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). In March 2025 it selected HQC as a backup encryption algorithm. Its draft transition plan, NIST IR 8547, proposes deprecating quantum-vulnerable algorithms after 2030 and disallowing them after 2035.

Federal policy has since set dates. Executive Order 14412, signed June 22, 2026, gives federal systems until December 31, 2030 to adopt post-quantum key establishment. We covered those milestones in our Executive Order 14412 deadline guide. The NSA’s CNSA 2.0 FAQ goes further on firmware. It urges signing systems to move first, because the code that checks a signature is often hard to update once a product ships.

That last point is the heart of the medical device cybersecurity problem. Enterprise laptops are replaced every few years. Clinical equipment is not.

The Cryptographic Lifespan Gap, Explained

Here is the arithmetic. A connected device bought in 2026 and kept for 10 to 15 years stays in service until 2036–2041. If the 2030 and 2035 dates in NIST’s draft hold, that device will spend years running cryptography that federal standards no longer accept.

Device purchased	Likely retirement	Years past 2030 deprecation	Years past 2035 disallowance
2020	2030–2035	0–5	0
2026	2036–2041	6–11	1–6
2029	2039–2044	9–14	4–9

These ranges are illustrative, not a prediction for any single product. The pattern is the point: the later a hospital waits to demand post-quantum readiness, the wider the gap it signs up for.

An FDA-commissioned white paper from MITRE, Managing Legacy Medical Device Cybersecurity Risks, makes the same point. It warns that devices being purchased today can already meet the definition of a legacy device. It also notes a mismatch between how long hospitals keep equipment and how long manufacturers support it.

Why patient data makes “harvest now, decrypt later” worse

Attackers do not need a quantum computer today to benefit from one later. They can record encrypted traffic now and decrypt it once the math breaks. We explain the tactic in Harvest Now, Decrypt Later, and the underlying math in Shor’s algorithm explained.

Health data is an ideal target. A credit card can be canceled. A diagnosis, a genetic result, or a psychiatric history cannot. Data that stays sensitive for a patient’s lifetime needs protection that lasts just as long.

What the FDA Already Requires for Medical Device Cybersecurity

The FDA has steadily raised the bar. Since March 29, 2023, section 524B of the FD&C Act has required makers of “cyber devices” to include cybersecurity information in premarket submissions. The FDA’s cybersecurity FAQ defines a cyber device as one that includes sponsor-validated software, can connect to the internet, and could be vulnerable to cyber threats.

Manufacturers must now:

Submit a plan to monitor, identify, and address postmarket vulnerabilities.
Provide a software bill of materials (SBOM) covering commercial, open-source, and off-the-shelf components.
Make updates and patches available to the device and related systems.

The FDA’s premarket guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, was updated on February 3, 2026 to align with the new Quality Management System Regulation. It lists cryptography among its recommended security controls. It also names secure and timely updatability and patchability as a core security objective. The agency’s postmarket guidance adds that networked devices need continual maintenance for their entire life.

Where the rules stop

None of these documents sets a date for post-quantum algorithms in medical devices. And as the GAO noted in GAO-24-106683, the 524B requirements do not reach back to devices already on the market before March 2023 unless a maker files a new submission. That leaves the installed base, which is most of what hospitals actually run, outside the new rules.

The Legacy Fleet Hospitals Already Own

Healthcare delivery organizations inherit the gap whether they planned for it or not. The FBI warned in a 2022 private industry notification that unpatched and outdated medical devices give attackers openings into hospital networks. The Health Sector Coordinating Council’s Managing Legacy Technology Security (HIC-MaLTS) guide describes the same shared burden between makers and providers.

The risk is not theoretical. In January 2025, the FDA issued a safety communication on certain Contec and Epsimed patient monitors. It pointed to CISA advisory ICSMA-25-030-01, which described hidden functionality and patient data being sent outside the care environment. The FDA’s advice was to cut the monitors off from the internet.

When the fix for a device is “disconnect it,” the network becomes the only control left. That is exactly where post-quantum protection can be added without waiting for firmware.

The stakes are high. An analysis of 2025 OCR data counted 710 large healthcare breaches exposing more than 61.5 million people’s records. Every one is listed on the HHS OCR breach portal. We saw the downstream damage in the Change Healthcare hack.

Why Post-Quantum Cryptography Is Hard on Medical Devices

If swapping algorithms were easy, the gap would close on its own. Four constraints make it hard.

1. Bigger keys and signatures

Post-quantum keys and signatures are much larger than the ones they replace. Per the FIPS 203 and 204 parameter sets:

Function	Classical (today)	Post-quantum (NIST)
Key exchange public key	X25519: 32 bytes	ML-KEM-768: 1,184 bytes
Digital signature	ECDSA P-256: about 64 bytes	ML-DSA-65: 3,309 bytes

On a battery-powered wearable or a low-memory controller, those extra bytes cost power, bandwidth, and storage.

2. Firmware roots of trust

Many devices verify updates with a key burned into hardware. If that check only understands RSA or ECDSA, no software update can teach it a new algorithm. This is why CNSA 2.0 favors the stateful hash-based signatures in NIST SP 800-208 (LMS and XMSS) for firmware signing now.

3. Validation and re-submission

Changing cryptography can mean new testing under the Cryptographic Module Validation Program and, for some changes, a new FDA submission. Our look at certificate lifecycle management and the FIPS 140-2 sunset covers why validation queues matter.

4. Protocols built for another era

Clinical networks still carry older protocols, flat VLANs, and vendor remote-access tunnels. We examined similar weak points in quantum computing’s impact on IPsec and why SD-WAN is not ready for next-generation attacks.

Regulatory Pressure Beyond the FDA

Medical device cybersecurity sits inside a wider compliance picture for providers:

The January 2025 Security Rule proposal would require encryption of ePHI with limited exceptions, a technology asset inventory, and network segmentation. It had not been finalized as of this writing, but it shows where regulators are heading.
HHS voluntary goals. The HPH Cybersecurity Performance Goals and the 405(d) Health Industry Cybersecurity Practices give hospitals a practical baseline, including asset management and medical device security.
Federal quantum readiness. CISA, NSA, and NIST’s joint Quantum-Readiness fact sheet asks organizations to build a cryptographic inventory and engage vendors now. Health systems that serve federal programs should also watch EO 14412 contract requirements.
Reference designs. NIST’s NCCoE offers SP 1800-8 on securing wireless infusion pumps and a Migration to Post-Quantum Cryptography

A Medical Device Cybersecurity Roadmap for Hospitals

Hospitals cannot rewrite vendor firmware. They can control what surrounds it. A practical sequence:

Inventory every connected device and its cryptography. Record the protocol, algorithm, certificate, and end-of-support date. A cryptographic bill of materials (CBOM) turns this into a living record.
Score each device by its lifespan gap. Rank devices by planned retirement date, data sensitivity, and whether their cryptography can be updated.
Segment clinical networks. Put devices in tightly scoped zones with zero trust policies, so a compromised monitor cannot reach the EHR.
Wrap device traffic in quantum-resistant tunnels. Protect the paths between clinical zones, data centers, clouds, and remote sites so recorded traffic stays safe.
Centralize key management. Rotate and govern keys in one place, rather than on thousands of endpoints.
Watch device behavior. Flag devices that suddenly talk to unknown destinations, as in the Contec case.
Protect the data at rest. Encrypt and back up the imaging archives and clinical data that devices feed.
Write post-quantum language into contracts. Make readiness a buying requirement, not a wish.

Six questions to ask every device manufacturer

Which algorithms does the device use for key exchange, signing, and storage today?
Can those algorithms be changed by a field update, or are they fixed in hardware?
What is your published roadmap for ML-KEM, ML-DSA, or LMS/XMSS support?
Will you provide a CBOM alongside the SBOM?
What is the end-of-support date, and what happens to security updates after it?
Does the device support hybrid classical plus post-quantum modes during the transition?

What Manufacturers Should Build Into the Next Submission

For device makers, medical device cybersecurity is now a design decision with a long tail. The strongest submissions will show:

Crypto-agility by design. Algorithms isolated behind interfaces so they can be swapped without a hardware change.
Quantum-safe roots of trust. LMS or XMSS firmware signing, with ML-DSA as validated modules fit the device.
Hybrid key exchange. Classical plus ML-KEM during the transition, so security never drops below today’s level.
Honest lifecycle dates. End-of-support timelines that match how long hospitals actually keep equipment.
A CBOM next to the SBOM. Buyers increasingly need to see cryptography, not just components.

How ibm/SEIMless Helps Close the Medical Device Cybersecurity Gap

Our view is simple: the fastest way to protect devices you cannot change is to protect the network around them. That is the thinking behind our Exodus QRN quantum-resistant networking suite.

Exodus QRN Data in Motion applies quantum-resistant encryption to traffic in transit, with optional stateful firewalling.
QR Edge extends quantum-resistant protection to the edge of the network.
Exodus Key Management centralizes key control across sites.
Exodus Aria ADR and the Exodus NxtGen Firewall add detection and policy enforcement around clinical zones.
Zero Trust Content Security and EDR protect the workstations that manage devices.
Exodus QRN Data at Rest, backup and recovery, and private and hybrid cloud services protect the records devices produce.

Because this protection runs at the network layer, it does not depend on a device maker shipping new firmware. Hospitals can start with their highest-risk paths this quarter, then extend coverage as budgets allow. For the full migration picture, see our post-quantum cryptography migration playbook and network edge security in 2026. For AI-driven clinical workflows, our analysis of blind agent transfer applies to healthcare just as much as finance.

Medical Device Cybersecurity FAQ

What is medical device cybersecurity?

Medical device cybersecurity is the protection of connected clinical devices, and the patient data and care they support, from unauthorized access, tampering, and disruption across the device’s full lifecycle, from design through retirement.

Does the FDA require post-quantum cryptography in medical devices?

Not by a specific date. Section 524B requires cybersecurity information, an SBOM, and a vulnerability plan for cyber devices, and FDA guidance recommends strong, updatable cryptography. It does not yet set a deadline for post-quantum algorithms.

What is the cryptographic lifespan gap?

It is the number of years a device stays in clinical use after the encryption it relies on has been deprecated. A device bought in 2026 and kept 10 to 15 years may run six or more years past NIST’s proposed 2030 deprecation date.

Can hospitals protect legacy medical devices that cannot be updated?

Yes, with compensating controls. Segmentation, zero trust policies, behavior monitoring, and quantum-resistant encryption of network paths protect device traffic without changing device firmware.

Why is health data a target for harvest-now, decrypt-later attacks?

Health information stays sensitive for a patient’s lifetime. Attackers can record encrypted traffic today and decrypt it once quantum computers can break RSA and elliptic-curve cryptography.

What should hospitals ask device manufacturers about quantum readiness?

Ask which algorithms the device uses, whether they can be updated in the field, the vendor’s roadmap for ML-KEM, ML-DSA, or LMS/XMSS, whether a CBOM is available, and the end-of-support date.

Protect Patients Before Q-Day Arrives

Every connected device in your hospital carries a patient’s trust. ibm/SEIMless and Exodus QRN help healthcare, financial, and insurance organizations close the medical device cybersecurity gap at the network layer, without waiting on firmware. Let’s map your highest-risk device paths together.