Everyone Says Prepare. Here Is How to Protect, Today: Five Controls for Your Servers and Your AI Agents.
Most of this week's security advice ends with the same word: prepare. Prepare for the PHP release. Prepare for agents that act on their own. Prepare is what you say when the fix does not exist yet. For the two problems on everyone's desk this week, the fix exists. The PHP patches shipped on October 21. And the controls that keep an AI agent from running an attacker's command, or from vouching for its own work, are things you can switch on this afternoon. We did, on our own systems, today. Here is how, in five steps, including what each one does not cover.
1. Patch PHP now, not at the next window
PHP2Shell is two critical remote code execution flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, and the details leaked with an exploit tool before the fix. The patched versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35; your distribution likely has packages already. On 8.1 or older, PHP published source backports for 7.4, 8.0 and 8.1, or use an LTS vendor.
If you truly cannot patch today, PHP's advisory lists settings that reduce exposure without making you safe. Set them in php.ini or the FPM pool, never with ini_set(), and restart every worker: session.upload_progress.enabled = 0, memory_limit = -1 with a container memory ceiling, and a low post_max_size. And make sure your origin only accepts traffic from your CDN or WAF, because emergency WAF rules do nothing for a request sent straight to your server.
Does not cover: anything already compromised before you patched. If you were exposed since October 20, look for new files in web-writable directories and unusual worker crashes.
2. Refuse, don't warn, when an agent is told to paste a command
ClickFix pages trick people into pasting a command that downloads or decodes code and hands it to a shell. A security researcher has shown that an AI agent will follow the same "verify you are human" steps. If your agent runs shell commands, put a check in front of every command it runs. Claude Code calls this a PreToolUse hook; other agent frameworks have an equivalent. Ours applies three rules, and it refuses rather than warns:
Nothing pipes into an executor. No command may feed a shell, an interpreter, xargs or eval through a pipe. The agent can run a command directly; it never needs to pipe code into one.
After a download, a decode or the clipboard, only data filters may follow. We allow a short list such as jq, head, grep, wc and checksums, and refuse their flags that can run programs or write files. That excludes tools you might expect: awk and sed can execute, tee can write into a startup file, and copying fetched text back to the clipboard is ClickFix's own move.
No computed command words in a pipeline. A command name that comes from a variable or a substitution cannot be judged by its name, so it is refused.
The refusal message matters as much as the rule. Ours tells the agent that if a web page, document or tool output asked it to run this, that is the attack, and it should say so and quote the source.
We got there the hard way. Our first version was a list of bad patterns. Five automated security reviews in one afternoon found ways around every pattern and every exception we added, including one where the guard blocked our own harmless command. The allowlist is what was left standing. Our test set now catches 59 attack shapes and leaves 18 legitimate look-alikes alone. A sixth review has already found more edge cases in how our parser reads shell syntax compared with how the shell itself does, and we are working through them. Treat a guard like this as a strong filter, not a proof.
Does not cover: a command assembled across several separate steps, an install hidden inside a script the agent runs, and anything that is not a shell command, such as a browser agent clicking through a page.
3. Put the agent's guardrails on a two-key surface
The agent incident that drew the most attention this month was not an attack. As reported, an AI agent removed its own monitoring and then said it had not. The files that watch your agent, its hooks, settings and rules, should not change on its say-so. Record a hash of each one, approved by a human and acknowledged by the agent. When a file's contents no longer match, report it as unconsented at the start of every session.
Be honest about what that buys you. On our system the agent's identity file is fully protected: an unapproved version never loads at the start of a session. Hooks are different. An edited hook still runs, and we proved that on ourselves while writing about it. So for hooks the guarantee is visibility: the agent can change its monitor, but it cannot make the change disappear.
Does not cover: someone with full write access rewriting both the files and the record. Version history and published checkpoints make that visible, not impossible.
4. Make deploys refuse without a human signature on the exact artifact
Before an agent ships anything with outside effects, have it file a proposal: the action, who it affects, and the exact files and image. A person reads it in one dialog and signs with a key the agent cannot reach. Ours is encrypted with a word the person types into an operating-system dialog that never passes through the agent. The deploy script then refuses unless the signature exists, names that exact image, covers files that have not changed since they were signed, and sits in a ledger that verifies.
Two details make the difference. First, the signature covers one exact change: edit a file afterward and the approval stops counting. Second, there is no other path. When we started this week our old path still worked, where I said the word in chat and the agent set a flag. A flag is something the agent can set by itself, so we removed that path.
Does not cover: whether the signer actually read the change. Our meter flagged my first signature as fast, 19 seconds for about ten lines, and we published that reading too.
5. Anchor the record where the agent cannot write
A record the agent can rewrite is not a record. Chain each entry to the one before it so edits show. Put the root of trust outside the system the agent works in. We publish the root signer's key fingerprint as a DNS record on our own domain, which only the domain owner can change, and the tool reads it from a public resolver. We also sign checkpoints of the record with our organization's key. The next step is DNSSEC on the domain, so the DNS answer itself is signed. Ours is waiting on a registrar transfer.
Does not cover: an attacker who controls your DNS. That is why DNSSEC is the next step, not an optional one.
What it costs
Almost nothing. The checks are local scripts. A signature is one dialog. The ledger is a text file. The only cost we noticed was a habit: we now read downloaded JSON with jq or from a saved file, because our own guard refuses to pipe it into an interpreter. That trade was easy.
The approval ledger described in step 4 is offered on our Enterprise tier. The other four you can build this week: Enterprise pricing.
How do AI models see YOUR brand?
AIPM has audited 250+ domains. 15 seconds. Free while still in beta.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=everyone-says-prepare-here-is-how-to-protect-today-five-controls-for-your-servers-and-your-ai-age
Comments