On 21 October, two security advisories were published for PHP, CVE-2026-109618 and CVE-2026-109619. One of the production systems we run, an online business we operate ourselves, was on an affected version.
Here's what happened next, because it's a good example of how we think security should work.
What happened
- An agent noticed. An agent that monitors the system picked up the advisory, checked the production server, and confirmed it was running PHP 8.4.16, an affected version.
- An agent proposed the fix. It recommended moving to the patched release, PHP 8.4.27, and laid out the risk, the change, and how we'd know it worked.
- Another agent prepared it. The upgrade and the checks to run afterwards were set up and ready to go.
- A person approved it. I read the proposal and said yes. Nothing touched production before that.
- The agent ran it and proved it. The upgrade went out at 23:15 that night. The agent then confirmed the PHP service was running, the site was responding normally, and document generation, the part of the business customers pay for, still worked.
We also learned something. Our hosting platform doesn't apply PHP security releases automatically, so checking after every PHP security release is now a standing job for an agent, not something a person has to remember.
Why this matters
In a lot of companies, the same story goes differently. The advisory lands in someone's inbox. Maybe they see it. A ticket gets opened. It waits for the next maintenance window, or for the one person who knows how the server is set up to come back from holiday. Days or weeks go by on a known vulnerability.
None of that delay comes from the hard part. Deciding whether to apply a security patch to a live business is a judgment call, and it took me a few minutes. The delay comes from the routine parts around it: noticing, checking, preparing, verifying. Those are exactly the parts agents are good at.
Agents do the noticing, the preparing and the checking. A person makes the call.
That's what we mean by agent first, human in the loop. It isn't human-free. Accountability for a production system can't be handed to software, and we wouldn't want it to be. But the person's time goes to the one decision that needs them, not to the forty minutes of busywork around it.
Why boring technology helps
This went smoothly partly because there was very little to go wrong. The system runs on a modern, well-understood stack on a single, simple server. The fix was one version change and a short list of checks.
Many security problems live in the seams of older setups, where several systems are held together with hand-built glue and nobody is sure what a change will break. Every one of those seams is a place to defend. We'd rather not create them in the first place, which is why we build light and simple, and keep agents watching what we've built.
What we'd tell a business owner
- Ask your team how long a known security patch typically waits before it's applied, and why.
- Most of that wait is routine work. Routine work can be given to agents.
- Keep a person approving changes to anything customers touch. Always.