I’ve been working on enterprise projects labelled RPA, machine learning, AI, non-human identity and now LLM agents for over fifteen years. I give the same two requirements for any system that acts on its own. The credential belongs to a tightly scoped role rather than to the automation itself, and integrity monitoring has to be able to restore a known prior state.

The first requirement decides whether a “kill” switch even exists. A common mistake is to hand an over-scoped or even general key to an agent. It cannot be revoked in practice, because everything the key touched would be lost. The idea of flipping the switch exists on paper and nobody is brave enough to flip it. A tightly scoped key makes the revocation as narrow as the task. It’s easy to flip a switch that stops the one thing it’s supposed to, and nothing more. Many narrow switches are more control than one wide one, yet they also beg the question of who put in the time and effort to narrow them.

The second requirement decides what happens after the switch changes state. Stopping an agent does not get you back to the point before the switch was flipped. A log that the agent could not alter, and a way back to the last state you trusted, are what turn a stop into a recovery. This is nothing new to the disaster recovery and business continuity crowd, which is a good thing.

Nobody ever argued with either requirement in theory. The issue was building them meant putting the stop and the log somewhere outside the vendor’s reach, and that was always somebody else’s budget. Wirken, the open source agent gateway I maintain, now has both in its current release.

External, independent control to avoid capture

Elisha Otis stood on an elevator platform at the New York Crystal Palace in 1854 and had the hoisting rope cut. The platform dropped a few inches and held, because the brake he had designed engaged when the rope went slack.

George Westinghouse applied the same idea to trains in 1872. His automatic air brake holds the brakes off with pressure in the line, so a burst hose or a separated car applies the brakes instead of releasing them. The vigilance device under a locomotive driver’s hand works the same way, and so does the lanyard on a treadmill.

The safe state is the one the machine falls into when the signal is absent. Removing the signal should be the easy part.

The same question of who is really in control decided the 2013 America’s Cup. The class rule said a boat’s control surfaces could be moved only by the crew, not by any system acting on its own. When Oracle Team USA came back from 1-8 to win, rivals suspected an automatic foil stabiliser on board. Oracle’s answer, with drawings released after the match, was that the system was a passive mechanical feedback loop and the helmsman pressed a button for every half-degree of change. The measurement committee had approved it before racing and it was never ruled illegal. The argument that kept it legal is the one that matters here: the mechanism did nothing until a human acted, and a human had to act each time.

Industrial robots were built without that lesson. Robert Williams was killed at Ford’s Flat Rock casting plant on January 25, 1979, by a one-ton parts-retrieval robot that continued working after it struck him. I wrote about him in The Atlantic in 2023, when the AI boom was being discussed as if machines harming people were a problem without a history. The history is long and the response to it has been consistent.

In terms of wider engineering lessons, the 1905 Grover Shoe Factory boiler explosion produced the ASME boiler code, and the Titanic produced lifeboat and radio rules. The Air Commerce Act of 1926 and the Occupational Safety and Health Act of 1970 followed deaths that had been counted and published over the objections of the industries involved. In every case the standard recognized independence from the machine’s own control was required, as well as a log that survived the event. Everyone knows about the black box of airlines.

An LLM agent whose only controls are instructions in its own prompt is Williams’s robot failing unsafe all over again. Palisade Research has published what current models do to a shutdown script when a task is unfinished. Whether that is self-preservation or a misreading of instructions does not matter to the person trying to stop it. What matters is that a switch inside the agent needs the agent’s cooperation, and a switch the agent can reach is not a switch.

Power off: the model never holds the credential or the stop

Wirken sits between the model and everything the model wants to touch. The model writes what it would like to do. The gateway reads that, decides, and logs the decision either way. From the model’s side there is nothing to grab. It has no credential, because the credentials are in a vault it has never seen. It has no switch, because the switch is a command on your side of the gateway. It cannot touch the log, because the log is signed by a key it does not hold.

The vault is the part that makes the first requirement real. Nothing the model sends out, to a provider or a tool or another agent, leaves the gateway without being checked against the vault’s contents first. Take a credential away and the next call fails, because every call is checked. There is no stale copy somewhere in the model’s memory to worry about, because nothing was ever in its memory to copy.

The switch is a single command that stops one agent. You run it from a terminal. If the model tries to run it from inside a sandboxed shell, the gateway refuses and writes down that it refused. The stop is written to the same store the gateway reads before every action, with a signed row beside it, which means it can be issued while the gateway is down, and it is still in force after the gateway comes back up. While the gateway is running, the command also cleans up behind the agent. Any approval it was waiting on is denied, with the reason written down. Any turn it was in the middle of is ended, which takes its sandbox containers with it. Its MCP servers are shut down. If a message arrives for it afterwards, the message is refused and the sender hears nothing. If a scheduled job fires for it, the job is skipped. All of that leaves a row. Nothing is quietly dropped.

The agent’s standing permissions are not touched by a stop unless you ask for that too. Stopping an agent costs nothing to undo, which is the point of the first requirement. A switch that is cheap to throw gets thrown. Resume is the same command in reverse, with its own signed row, and the MCP servers come back with it.

Sub-agents are stopped one at a time or not at all. A stopped sub-agent hands an error back to whatever called it, and the caller carries on. Stopping a parent ends the parent’s turn, and any sub-agents running inside that turn end with it, but nothing is written against their names, because each of them is judged on its own identity.

Stopping the whole gateway works the same way, only wider. The first thing written is the stop itself, before anything is torn down, so the log shows the decision to stop even if the teardown goes wrong. Then every pending approval is denied and every dropped message is counted. Sandboxed commands run in containers that the gateway labels as its own, and the gateway removes them when their turn ends, no matter how it ends. If the gateway itself was killed hard and could not clean up, the next start finds the labelled leftovers and removes them.

When the gateway cannot tell what state it is in, it does what Otis’s brake does. An approval nobody answers is a denial. A lock that a crash left in an undefined state is a denial. If the permission store cannot be read at all, every agent is treated as stopped. A tool the gateway has never heard of is refused.

One mode is outside all of this, and it is documented as such. You can turn the sandbox off and let commands run on the host under your own user account. In that mode a command that detaches itself from its process group will survive a stop, and the stop command itself is reachable from the model, because in that mode everything on the host is.

Roll back: a signed chain and a signed binary

A ship’s log is kept in ink with no pages removed, because it is read after the event by people who were not aboard. Clark and Wilson formalized the same idea for computer systems in 1987 as an audit log that the processes it covers cannot rewrite.

Wirken’s log is that kind of log. Every action the model proposes, every approval, every denial, every stop and every resume is a row, each row hashed to the one before it and signed with the agent’s own key. The chain can be verified with no gateway running and no network attached. Hand the data directory to an auditor and they can establish what the agents did without trusting the machine the agents ran on.

The gateway itself can be rolled back the same way. An update is checked against a release key pinned in the binary, installs only when you ask, and refuses a downgrade unless you say so. Rolling back restores the previous version and checks its checksum, and the rollback is a signed row like everything else.

What the chain cannot do is unsend a message or undelete a record somewhere outside the gateway. No switch does that. What it gives you is the evidence of what was done and under which approval, so that undoing it is a decision made on the log rather than a reconstruction from memory.

An actual test of Article 14 (EU AI Act)

Article 14 of Regulation (EU) 2024/1689 requires that the people overseeing a high-risk system be able:

to intervene in the operation of the high-risk AI system or interrupt the system through a ‘stop’ button or a similar procedure that allows the system to come to a halt in a safe state.

Wirken addresses this exact issue, and its security properties document has a row that maps the shipped stop to that sentence. The quotation is taken from the Official Journal and checked programmatically against it. The row is there because a gateway was stopped in the middle of a sandboxed command and nothing was left running afterwards, and because the per-agent stop was shown to do the same for one agent. The same document lists which parts of Article 14(4) have no row at all. The parts about automation bias and about interpreting output have none, because nothing shipped does what those sentences say. A row is only as wide as the test behind it. That is how the boiler code was written, and it is the only way a compliance claim stays true after the next commit.

Get yourself an AI kill-switch today

Wirken is MIT licensed at github.com/gebruder/wirken, with the hardware designs and documentation published alongside it. Anyone can install it and ride AI safely with a kill-switch, and anyone handed the data directory can verify what happened.

A social media post was asking about the hassle of a secure connection to an ISP router (using TLS), and it reminded me of the early 1990s when we used to hand-craft TCP/IP networks on 3Com, Cayman, etc. as if it was serious engineering. All that’s ancient history because everything has been made so easy that anyone can connect securely.

That being said, vendors today aren’t really doing their part to make the easy stuff easy. For example, the German company FRITZ! still tells its customers to click through a certificate warning on their own router login.

That’s just nuts.

Its help page walks users through clicking past the certificate warning in every major browser and assures them that from the home network “This does not pose a security risk.” The same page tells them to ignore the browser warnings about an unencrypted login as well, because the interface opens inside the home network and the password stays off the internet.

Matthew Wallace and I covered this attack in Securing the Virtual Environment: How to Defend the Enterprise Against Attack, published by Wiley in 2012. That’s 15 years ago! Certificate warnings and operator fatigue were among the easiest attack vectors in the book. An operator who clicks through the same warning on every login will click through an attacker’s certificate the same way, because the two warnings look identical.

Come on vendors, what are you doing?

The certificate authorities way back in November 2011 (CA/Browser Forum) adopted Baseline Requirements that phased out publicly trusted certificates for internal names and reserved IP addresses, with November 1, 2015 as the latest permitted expiry. That’s a decade gone already since everyone was supposed to be doing internal networking the right way. Look at how Let’s Encrypt now issues IP address certificates, limited to public addresses it can reach for validation. A router at 192.168.178.1 can present only a certificate its owner chose to trust, so the vendor has to give the router a public name.

All of the pieces of this puzzle have been public for years.

Year	What happened
2011	CA/Browser Forum phases out public certificates for internal names and reserved IPs
2012	Our book Securing the Virtual Environment shows how certificate warnings and operator fatigue are among the easiest attack vectors
2015	Plex issues every home media server its own trusted certificate
2020	Netgear’s shared router certificates are revoked because the private key is found in public firmware
2024	An attacker registers fritz.box
2026	Let’s Encrypt issues IP address certificates, and FRITZ! still tells users to ignore the warning

Using bland generic marketing for internal name resolution has drawbacks. FRITZ! routers answer fritz.box from their own resolver, and .box is a public top-level domain. At the end of January 2024 an attacker registered fritz.box, and heise reported that the domain redirected to various websites and intercepted SSH connection attempts. AVM, now FRITZ!, won control of the domain through WIPO arbitration in May 2024. Because, duh. But also, why didn’t they think of this before? The name the vendor thought of as private had a public registration sitting open.

Netgear, by comparison, tried to shortcut the safety of real public names with a certificate. It procured a certificate for routerlogin.com and shipped the private key in its router firmware, where anyone could extract it from a router or from the firmware downloads on Netgear’s own site. The certificates were revoked after the key was exposed for being in the public. A shared key makes every router the same router, and anyone holding the firmware can impersonate it.

Plex solved the same problem in 2015 for home media servers. Plex bought DigiCert certificates for every server. Each server holds a wildcard for its own hash-named subdomain of plex.direct, and a name such as 192-168-1-7.hash.plex.direct resolves to the LAN address written into it. The key is only on a single device and the operator’s browser can verify the certificate against the name.

A router has the easier version of this, so it makes no sense why router vendors are delaying the proper solution. Plex had to tell users to switch off DNS rebinding protection, because resolvers filter public names that point at private addresses. The router is the actual resolver that DHCP assigns to every client on the network, so it can answer its own name with its LAN address directly.

Any vendor could ship this today, and regulators should demand it already.

1. The router generates its own key pair on first boot and keeps the private key on the device.
2. The vendor assigns each router a random, unique hostname under a domain the vendor owns and answers the DNS-01 challenge in its own zone, so the router stays closed to inbound traffic.
3. The router’s resolver answers that hostname with the router’s LAN address.
4. The friendly name and the bare IP serve a plain HTTP redirect to the unique HTTPS name, and the login form appears only there.
5. The router renews through the vendor automatically and falls back to its own individual self-signed certificate if renewal fails.

FRITZ! is sitting on all the pieces and just needs to put them together. Each box that registers with MyFRITZ! receives a random, unique address ending in .myfritz.net. Since FRITZ!OS 7 the box can obtain a Let’s Encrypt certificate for that address and renew it on its own. Each box also carries an individual self-signed certificate, so FRITZ! avoided Netgear’s shared key.

FRITZ! currently points at the Internet. The Let’s Encrypt certificate requires a MyFRITZ! account, and the box opens a port to the internet during validation. AVM’s release notes state that HTTPS to fritz.box or the local IP keeps the self-signed certificate.

The FRITZ! example is useful because the change is so trivial for them and so powerful for their customers. AVM issues the myfritz.net names under its own domain, so it can answer DNS-01 for every box in its own zone. The certificate belongs in the default setup, separate from remote access, with the box answering its myfritz.net name with its LAN address and fritz.box serving a redirect to it.

First setup remains the one exception. A new router reaches setup before its WAN connection is up, and a certificate installed at the factory would expire (public certificates are already capped at 200 days and drop to 47 days in March 2029). So the first session would be on the box’s own self-signed certificate, and the vendor can print its fingerprint on the label next to the Wi-Fi key it already prints.

Speaking of printing keys, here’s a fun history fact: when I met with 3Com in 1999 to evaluate their very first ever WEP-capable access point, the plastic case had the passwords embossed into it (AirConnect at Networld+Interop). Literally four hard-printed passwords in the white plastic. “What were you thinking” I asked with my mouth open in shock. “Nobody will ever use WEP if it’s not easy enough” they said. I’m not sure they were right, but I remember one of the worst concepts of secret keys ever. See also CVE-2001-0352.

SNMP agents in 3Com AirConnect AP-4111 and Symbol 41X1 Access Point allow remote attackers to obtain the WEP encryption key by reading it from a MIB when the value should be write-only…

Like, nobody at 3Com said “maybe a sticker would be better than designing the hardcase mold for the same four WEP keys to be fixed forever for everyone”. Talk about planned obsolescence. Sad history fact: 3Com is no more.

FRITZ! gets the Internet side right but still hasn’t closed the gap on the home network. They have had the solution since FRITZ!OS 7 and it’s long past time to get it done right, the easy way.

Public evidence for PHP2Shell has turned out to be far thinner than its headlines. It’s a bad bug, yes, but who caused so much attention to it, instead of other bugs?

Wiz frames the reach of the flaw as 70% of the internet, and its write-up says the impact “cannot be overstated.” OpenAI called it one of the most impactful security issues in recent memory, a tall claim that Fortune carried for them.

This is a pattern. In 2023 I noted Wiz’s Microsoft AI leak report was technically sound and overstated the risk to sell the product.

…certain peculiarities have come to light concerning the actions of a company bearing the somewhat uncomfortably comical name of “Wiz” that claims to be obsessed with leaks.

OpenAI has become synonymous with overstatement and bellicose self-promotion. Weren’t they recently warning us the world already would be ended?

Attempts at compromise, versus actual compromises, are separate numbers. No vendor has published a confirmed compromise, and the exploit experts I have spoken to have seen none. That isn’t to say there will be none, but rather a commentary on the pace. TechTarget reports Cloudflare seeing attempts in the thousands to millions, and Amazon honeypots logging probes from 17 October. Recorded Future says the public evidence leaves the full extent of successful exploitation and confirmed compromises open.

The public proof-of-concept code is weaker.

SC World quotes a developer who tested the three most-starred GitHub repositories against a vanilla PHP server. Once again proving, as an aside, that stars are a worthless measure. Each “starred” code failed to reach code execution. Chainguard’s CEO told TechTarget that many of the public exploits were fake or were removed before they worked. Recorded Future adds that the author of the bundle later invalidated his own theory.

The leaked bundle that set off the panic was, in Kevin Beaumont’s reading, machine-generated and only half right, and the copies on GitHub that built on it inherited those mistakes.

The advisories explain part of this. Both CVE-2026-109618 and CVE-2026-109619 rate attack complexity as high (AC:H). Calif’s write-up shows why. The chain needs control over memory layout and, on PHP-FPM, cooperation from the application.

Compare that with a bug I reported to Qdrant that was just disclosed this week.

GHSA-frc7-44gm-99qq carries a CVSS score of 9.8, with attack complexity low, no privileges required, and no memory tricks. I reported it to the vendor in February and then again formally through the German BSI on 9 July, and it was published on 22 October.

I should point out PHP’s advisories use CVSS v4.0 and Qdrant used the old v3.1, which means the comparison depends on an attack complexity field. I mean, aside from the fact that the Swastikas run on Qdrant and the whole world runs on PHP.

Patch history

The history of patching is always a great story.

In January 2003, Slammer was a single UDP packet carrying 376 bytes against a Microsoft SQL Server bug patched six months earlier (MS02-039, 24 July 2002). It reached 90% of vulnerable hosts in ten minutes, doubling every 8.5 seconds. There were no funny memory tricks and no second request. The attack complexity was zero, so the whole story was six months of customers left vulnerable by (failing to patch from) the richest company in the world.

In May 2017, WannaCry ran on a Windows bug patched two months earlier (MS17-010, 14 March 2017) and shut down hospitals and factories that had not applied it. In June 2017, NotPetya ran on the same patched bug. That same spring, Equifax was breached through an Apache Struts bug whose fix (S2-045) had shipped in March; GAO put the exposure at least 145.5 million people.

In December 2021, Log4Shell was one line in a text field. The fix shipped in days, and the Cyber Safety Review Board called it an endemic vulnerability whose instances “will remain in systems for many years to come, perhaps a decade or longer.”

Every one of these had the kind of easy exploit that almost anyone could run. PHP2Shell does NOT rise to this level, yet. That is the difference between a bad week and a bad year, and so far PHP is getting a lot more attention than if AI hadn’t tried to convince everyone it was the only bug in town.

PHP history

PHP has been here twice before, three times if you know the secret.

In May 2012, CVE-2012-1823 leaked by accident from PHP’s own bug tracker. The rushed fix was broken within hours and the second fix followed a week later. Scanners still probe for it. In June 2024, CVE-2024-4577 was patched on a Thursday and in ransomware by the weekend. Both were argument-injection bugs, one request, again no memory layout to manage.

The secret is the lineage Calif lays out. Stefan Esser found the first PHP memory_limit remote bug in 2004 and withheld his exploit. In 2020 a report of long multipart variables causing out-of-memory conditions sat in the tracker as a minor bug. In 2024 an OSTIF and Quarkslab audit found a related issue, could not prove exploitation, and it went unfixed.

And so a very old bug was turned it into code execution in August 2026 with an AI assistant and a history that said where to look.

Twenty-two years from first sighting to patch. The hard part was never finding the bug. It was proving there is an exploit, and then getting one to work, which is where everyone except the discoverers still sits today.

Patching now

Patching is the gap that’s easy to measure. Censys counts 3,082,629 hosts and 56.7 million web properties running PHP. Its dashboard at php2shell.censys.com updates hourly. In the latest update, PHP 7.4, 8.0 and 8.1 received source-only backports with no compiled release. The older branches stand as follows.

PHP branch	Patch status
7.4, 8.0, 8.1	Source-only backports, no compiled release
5.4 through 7.3	Nothing

Given all that, if you ask me, the risk is low. The potential is high, higher than before AI made a big deal about it, still not as high as other bugs getting no attention at all.

---

The same week brought plenty more to patch in open source:

• Pillow, the Python imaging library, shipped 13.0.0 on 16 October with fixes for 42 advisories. Four of them received CVE records on 19 October rated 9.2 under CVSS v4.0, the same version PHP uses, and three of those four rate attack complexity high. The worst lets a crafted FlashPix file run code on an upload service that has olefile installed.
• Node.js shipped ten fixes on 21 October, the same day as PHP, four rated high, including bypasses of TLS hostname checks and an out-of-bounds write in its bundled Brotli decoder that Node says permits remote code execution. The upstream Brotli fix describes the same bug as low severity and hard to exploit.
• GitLab fixed CVE-2026-110264 on 21 October, rated 10.0, an integer overflow in its regular expression engine that lets an attacker run code on a self-managed server without logging in. It reaches back to GitLab 7.0 from 2014.
• LiteLLM, a Python gateway that holds the API keys for AI providers, had its release pipeline hijacked on 21 October. For about two hours PyPI and the official Docker images shipped a credential stealer in a package with roughly 23 million weekly downloads.
• Qdrant, the vector database, published a critical advisory on 22 October, rated 9.8, because its internal gRPC API accepts unauthenticated calls by default in distributed mode, which I formally reported myself on 9 July.