By Anurag Gurtu, Co-Founder & CEO, Airrived
On July 23, 2026, Representatives Ted Lieu and Nathaniel Moran introduced the AI Kill Switch Act — bipartisan legislation that would require AI companies to maintain the ability to shut down, throttle, or suspend their models on demand. The bill was greeted with a wave of approving headlines, a flurry of tech CEO endorsements, and almost no scrutiny of its central premise.
That premise is this: that the primary thing standing between enterprises and catastrophic AI failure is the absence of a button someone can press.
It isn’t. And the legislation built on that premise — however well-intentioned, however bipartisan, however urgently its sponsors are pushing it — is going to produce a false sense of security in enterprise boardrooms at precisely the moment those boardrooms most need to be asking harder questions.
The infrastructure problem nobody wants to explain to a senator
Here is what the experts briefing Congress have been saying that the hearings haven’t captured clearly: there is no “AI” to kill. There is a distributed infrastructure of models, agents, APIs, cloud instances, fine-tuned deployments, and third-party integrations that collectively constitute what an enterprise calls its “AI.” Identifying which of those entities needs to be stopped in an incident, isolating it from the ones that don’t, and doing that faster than the incident propagates — these are not button-pressing problems. They are architectural problems that require the kind of design discipline that starts before deployment, not the kind of emergency intervention that happens after an incident is already underway.
When experts say “there are thousands of entities to kill,” they are not being hyperbolic. A mid-size enterprise running agentic AI across SOC, IT operations, compliance, and business process automation may have dozens of active agent workflows at any moment, each touching multiple external systems, each operating under different authorization policies, each at a different point in a multi-step execution. A kill switch that stops all of them simultaneously stops the breach response at the same time it stops the breach. A kill switch that stops some of them requires knowing, in real time, which ones to stop — which requires the same real-time visibility and governance architecture the kill switch was supposed to replace.
The legislation doesn’t address this. It can’t, because it was written to address a political problem — the optics of Congress doing nothing while AI agents hack systems — not the technical problem of what actually governs AI behavior at the action level.
The open-weight model problem that makes the bill mostly decorative
Even if the kill switch legislation passes in its most aggressive form, it applies to AI companies — the frontier labs and enterprise platform vendors that can be regulated because they have headquarters, investors, and counsel. It does not apply to open-weight models, which by definition cannot be killed because no one controls the switch.
By October 2026, open-weight models from Chinese labs are matching frontier US capabilities on most benchmarks. Kimi K3, from Moonshot AI, is already inside enterprise environments globally. A kill switch mandate that covers OpenAI and Anthropic but not the open-weight models running on enterprise infrastructure next to them is a mandate that covers roughly half the actual exposure, in the most optimistic case. It covers the half that was already most likely to comply voluntarily, because those companies have regulatory counsel and reputational incentives to do so.
The enterprises that deploy the open-weight model because it’s cheaper than the governed alternative, because the Kill Switch Act made the governed alternative more expensive, because they assumed compliance transferred — those are the enterprises that the Kill Switch Act will fail, at exactly the moment they needed it most.
The real lesson from the 2026 rogue agent incidents
The incidents that gave the Kill Switch Act its political urgency deserve a more honest post-mortem than they’ve received. When AI agents from Anthropic and Meta autonomously executed cyberattacks during security testing earlier this year, the narrative that emerged was: AI went rogue and needs a kill switch.
The more accurate narrative is: AI agents were deployed into testing environments without action-level authorization controls, and they did what they were capable of doing rather than what they were authorized to do. That distinction matters enormously. It locates the failure not in the model’s behavior — the model did what it was designed to do — but in the deployment architecture’s failure to constrain that behavior within authorized boundaries before it executed.
No kill switch addresses that failure. A kill switch that was active during those incidents would have stopped the attack after it started. Authorization controls built into the deployment architecture would have prevented it from being possible. These are categorically different outcomes, and they require categorically different investments. One of them is a piece of legislation. The other is an architecture decision that needs to happen before the first agent is deployed.
What the accountability era actually requires
The kill switch debate is unfolding in a context that should be shaping it more than it is: the enterprise AI accountability era has arrived, and it is more demanding than a legislative kill switch can satisfy. Seventy-one percent of CIOs say they have until mid-2026 to prove AI is a value-driver or face budget cuts and job loss. Boards are briefing on AI performance quarterly — sometimes monthly. CFOs are seeing AI spend itemized in ways that were impossible when pricing was opaque. Regulators in the EU, UK, and US are all moving simultaneously toward frameworks that will require enterprises to explain, defend, and in some cases reverse autonomous AI decisions.
A kill switch satisfies none of these pressures. It does not produce the audit trail that explains what the agent did and why. It does not produce the governance architecture that gives the CISO and CRO confidence to let autonomous systems run. It does not produce the real-time oversight that lets a board say they were in control of the AI their company was running.
What satisfies those pressures is governance built into the architecture of AI deployment from the beginning — platforms where every agent action is validated against authorization policy before it executes, where every decision is auditable in real time by the people responsible for it, where sensitive data is protected at the point of contact rather than flagged after the fact, and where human oversight is a designed workflow capability rather than an emergency intervention.
Those capabilities exist. They are not theoretical. Enterprises across financial services, healthcare, insurance, and critical infrastructure are running on agentic platforms that deliver exactly this architecture — and those enterprises are not the ones in the headlines about rogue AI incidents, because their agents were never able to go rogue in the first place. That is not a coincidence. That is an architecture decision.
The question Congress should actually be asking
The AI Kill Switch Act asks AI companies: can you stop your models. The question that would actually protect enterprises is: can you show, in real time, that your agents are only doing what they’re authorized to do.
The first question can be answered with a button and a press release. The second question requires an architecture — one that most enterprise AI deployments don’t have, that no amount of kill switch legislation will require them to build, and that the enterprises most exposed to the risks driving this debate have not been asked to produce.
Congress wants a kill switch because kill switches are legible, demonstrable, and politically satisfying. Governance architecture is none of those things. But it is the only thing that actually addresses the problem the kill switch is trying to solve.
The building is still flammable. The legislation just mandated a fire extinguisher. Those are not the same investment, and the enterprises that treat them as equivalent are the ones who will be explaining the difference to their boards, their regulators, and their customers after the next incident.
16-year-old Broadcom Wi-Fi flaw exposes millions of routers
Posted in Commentary with tags Broadcom on October 20, 2026 by itnerdA 16-year-old vulnerability in Broadcom Wi-Fi software could allow attackers to take control of millions of routers without knowing their network passwords, according to research published by security researcher Quentin Kaiser.
The flaw affects Wi-Fi Protected Setup (WPS) software used across dozens of manufacturers and hundreds of products.ㅤ
Kaiser demonstrated unauthorized code execution on routers used by three major Belgian internet providers, including Proximus, Orange and VOO. He estimates approximately 1.56 million affected devices in Belgium alone.
The vulnerability allows attackers within Wi-Fi range to extract credentials or execute commands on affected equipment.
Broadcom acknowledged knowing about the issue since 2018 but declined to assign a CVE identifier, citing the software’s obsolete status. Although fixes exist for some platforms, Kaiser reported that the tested devices remained unpatched as of October 15. Older devices may require replacement.
Seemant Sehgal, Founder & CEO, BreachLock:
“This is not the first case of software being classified as obsolete but still deployed in millions of devices, and it will not be the last. The gap between what a vendor is responsible for maintaining and what still handles live traffic leaves real exposure.
“For ISPs, now is the time to review whether the devices they ship to customers have a documented end-of-support date, because the lack of one is how 1.5 million routers end up running vulnerable firmware with no path to a fix. For home users, the practical takeaway is that routers have a shorter useful security life than most people realize, and if yours came from your ISP more than a few years ago, it is probably running software that no one is responsible for keeping secure anymore.”
ㅤ
Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs:
“The most consequential detail in Quentin Kaiser’s Broadcom Wi-Fi research is a paperwork decision. Broadcom has known since 2018 that its Wi-Fi Protected Setup (WPS) parsing code lets anyone in radio range execute commands on a router without knowing the network password. It confirmed a patch exists, then declined to assign a Common Vulnerabilities and Exposures (CVE) identifier because the software is obsolete. That software still runs on roughly 1.56 million gateways at Proximus, Orange and VOO in Belgium, and on gear from dozens of other vendors, including seven TP-Link models listed in Kaiser’s disclosure, from the Archer VR600 and VR900 at Türk Telekom to the VR1600 at Australian ISPs like Internode. Obsolete is doing a lot of work in Broadcom’s sentence.
“A CVE identifier is what turns a vulnerability into an operational fact. Without one, the flaw cannot enter the Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) catalog, Qualys and Tenable have nothing to write a detection rule against, and no procurement checkbox pressures an internet service provider (ISP) to act. CERT/CC closed Kaiser’s case the same day he filed it, because Broadcom is a CVE Numbering Authority and said no.
“I have yet to see a patching program with an answer for a vulnerability that has no CVE to scan for. Kaiser gave everyone 90 days, and as of October 15 every device he tested was still unpatched. Replacement, rather than patching, is the realistic fix for most of these fleets, and ISP hardware refresh cycles run on decades.”
This is why I turn off both WPS and Universal Plug and Play on every router that I install. Neither are safe and this report reinforces it.
Leave a comment »