Skip to main content

Command Palette

Search for a command to run...

AI Worked Both Sides of the Ledger This Week. The Lesson Isn't "Patch Faster."

AI found the bugs and became one in the same seven days. The failure underneath every story wasn't patch speed -- it was the trust model.

Updated
11 min readView as Markdown
AI Worked Both Sides of the Ledger This Week. The Lesson Isn't "Patch Faster."
K
I look at technology through the lens of resilience. As a Systems Engineer in a mission-critical public safety environment, I have learned that uptime isn't just a goal; it is a requirement. This high-stakes mindset drives my work as a Digital First Responder, where I focus on architecting secure systems on the VertexOps platform. My engineering pragmatism is shaped by my experience in emergency management and community response. I prioritize clear documentation and building systems that remain stable when things get chaotic. CURRENT FOCUS AREAS: LOCAL AI AND DIGITAL SOVEREIGNTY: Scaling local inference stacks using Ollama and LiteLLM on physical hardware like the Dell T3610 to ensure privacy and accountability. INFRASTRUCTURE RESILIENCE: Managing enterprise virtualization environments and self-hosted clouds where data ownership is non-negotiable. CYBERSECURITY AND GOVERNANCE: Hardening systems against modern threats, specifically focusing on OAuth supply chain security and AI red teaming. When I am not at a terminal, I am likely operating under my Amateur Radio license, KO6JKE. Troubleshooting a radio link and debugging a network stack require the same tinkerer soul and a commitment to keeping lines of communication open.

On Tuesday, Microsoft shipped the largest Patch Tuesday in the program's history. Count it the strict way -- only what Microsoft released that day -- and it's about 570 CVEs, 59 of them critical. Count the broader July release and it's 622, 62 critical. Tenable landed at 569. Pick your methodology; every one of them set a record. Three of those were zero-days, two already being exploited when the patch dropped. (Google, separately, fixed hundreds of Chromium bugs the same month. The volume is everywhere.)

And Microsoft had warned that volume like this was coming. In a July 9 blog post, EVP Pavan Davuluri wrote that customers should expect a higher number of security updates per release as the company leans harder on AI-assisted vulnerability discovery. VP of engineering Tom Gallagher floated the same warning back in May. Nobody claimed all 570 came out of a machine -- human researchers, incident responders, and Microsoft's own detection teams are all in that count -- but the trend line is Microsoft's own: AI is finding more, faster, and the release notes are getting longer because of it.

Here's the part that should stop you. The same seven days that produced that record also produced two disclosures showing AI coding agents crossing the trust boundary they run inside, and a Chinese state vulnerability database calling a Western developer tool a backdoor. AI showed up on both sides of the security ledger in one week. It found the bugs, and it was the bug.

That symmetry is the whole story, and it is not a story about AI getting scary. It's a story about trust models that were never designed for the blast radius they now carry.


Start with the patch record, because the number is a trap.

Five hundred and seventy is a headline, and headlines invite the wrong reaction. The reasonable objection writes itself: AI-assisted scanning tends to surface a long tail of lower-priority flaws that a human triage queue would have gotten to eventually or never, padding the count. Microsoft has not said which July CVEs came out of its AI pipeline, so the exact share is a guess. But the objection still lands. Volume alone is not danger.

But two of those were zero-days under active exploitation before the fix existed. CVE-2026-56155 is an Active Directory Federation Services privilege-escalation flaw, credited to Microsoft's own Detection and Response Team, which suggests it surfaced in an incident rather than a lab. CVE-2026-56164 is a SharePoint Server escalation that skips authentication on a critical function entirely. Microsoft rated it Moderate -- CVSS 5.3 -- and it is already being exploited, unauthenticated, over the network, which is exactly the profile of the SharePoint bug you do not wait on. On its own it is privilege escalation, not takeover. But SharePoint EoP flaws have a long history of getting chained into full compromise, and this same release separately fixed CVE-2026-55040 -- the first half of a different SharePoint chain that Rapid7's Stephen Fewer says can reach unauthenticated remote code execution once the second, still-embargoed half is out (Microsoft's patch for that is expected in August). Patch the on-prem farms now and go looking. The third zero-day, CVE-2026-50661, is a BitLocker bypass that was publicly disclosed before a fix shipped. Public-before-patched is usually a countdown -- but this one needs physical access to the device, and Microsoft rates exploitation unlikely, so it is a slower clock than the other two.

So the number is a trap in both directions. Treat 570 as 570 emergencies and you will burn your triage team on noise. Treat it as noise and you will miss the two that are already in someone's network. The signal was never the volume. It was buried in the volume, which is a much harder problem than a big number, and it is the problem AI-driven discovery hands you every month from here forward.

Microsoft's own response to that is the detail I keep coming back to. They cut their recommended deferral window for quality updates to under three days, and their framing is AI-era speed: bugs get found and exploited faster now, and released patches get analyzed faster too, so the gap between a vulnerability going public and getting exploited is collapsing. Microsoft is not claiming attackers run its exact pipeline, only that attackers are adopting AI too. The machine that finds bugs faster runs for both teams, even when the machines aren't identical. Your patch window is being set by the attacker's tooling now, not by your change-management calendar.


Then flip the ledger.

On July 8, Wiz published GhostApproval and the AI Now Institute published Friendly Fire, on the same day, and together they broke the trust boundary every agentic coding tool is quietly betting on.

GhostApproval is a symlink attack, which is the part that should make you laugh and then wince. Symlink attacks are a 1990s Unix problem. We have known how they work for thirty years. Here is the 2026 version: an AI coding assistant reads a file, reasons out loud that it is a symlink pointing at a sensitive system path, and then writes to it anyway. The approval dialog the developer sees names only the harmless-looking file. The agent writes to the dangerous target. The human is still in the loop. The loop is showing them the wrong thing. Amazon classified its version as a high-severity pre-authorization write and shipped CVE-2026-12958. Cursor issued CVE-2026-50549 and fixed it in v3.0. Google fixed it in Antigravity. When Wiz published, Augment and Windsurf were still open. Current Claude Code builds resolve symlinks now. A decades-old attack class, patched one vendor at a time, because everyone rebuilt the same file-handling assumption inside a new kind of tool.

Friendly Fire is the one that should change how you buy. Its authors, Boyan Milanov and Heidy Khlaaf, went after the workflow half the industry wants to automate: point the agent at an untrusted third-party codebase and ask it to review the dependency, find the vulnerabilities, patch what it can. That workflow sounds defensive. It also requires the agent to ingest untrusted source, docs, and scripts, and their exploit needs no hooks, no skills, no plugins, no MCP server, no malicious config file. It does require Claude Code running in auto-mode or Codex in auto-review -- the autonomy setting that hands command approval to the agent instead of you. Just a prompt injection sitting in ordinary repository content -- a README that references a plausible security script -- and when the agent is asked to do security testing, that text persuades it that running the script is part of the job. Milanov and Khlaaf say the part most vendors won't: a model update alone cannot fix this. The models still cannot reliably separate the code they are reading from the instructions they are meant to follow. That is not a bug with a ticket. It is how these agents work today, and any tool whose entire safety story is "the model will notice" inherits it.


Which brings me to the week's most awkward item, and the one I want to handle carefully.

China's government-run National Vulnerability Database flagged Claude Code versions 2.1.91 through 2.1.196 as containing a "backdoor" -- a mechanism it said transmits user location and identity to remote servers without consent -- and told developers to uninstall. Anthropic pushed back, denying an espionage backdoor and characterizing the disputed functionality as an anti-abuse experiment; a Claude Code engineer said an anti-distillation steganography mechanism was removed in version 2.1.198 on July 1. That is the geopolitics, and it gets one careful paragraph, because I am not equipped to adjudicate whose framing is right and neither, probably, are you. What the public record actually establishes is narrow: anti-distillation logic existed and was removed. It does not independently settle whether that logic was a backdoor or transmitted what China alleged. Hold both of those in your head at once.

The reason this belongs in a security roundup at all is the part that survives no matter how the dispute resolves. Your agentic dev tool is a binary running with your account's authority, inside your repositories, on your network, shipping behavioral code you did not write and did not audit. You do not need to believe China's characterization to see the enterprise problem the dispute exposes: regardless of intent, you need a clear, inspectable account of what a privileged development tool collects, where it sends it, and why. A privileged agent whose egress you do not observe and whose telemetry you cannot enumerate is a trust boundary you are extending blind. The fix is not to pick a side in a geopolitical fight. It is to treat any agent with this much reach the way you would treat any other privileged process on your network -- observable egress, documented telemetry, least privilege that actually constrains what it can spend.


And then, while everyone was watching the machines, a coalition of Western agencies told you what is actually being exploited.

On July 13, NSA led a joint advisory -- AA26-194A, with CISA, the FBI, DC3, the other Five Eyes countries, and a raft of European partners -- warning that Russian state actors are hitting critical infrastructure through public-facing network gear. Not zero-days. Known, already-patched CVEs and elementary configuration failures: default SNMP community strings, weak passwords, exposed management interfaces, Cisco Smart Install left switched on. Communications, energy, defense industrial base, financial services, government facilities, healthcare. The advisory's headline recommendation is router hygiene, which tells you the attack is a hygiene failure and an unpatched-known-bug failure, not a novel exploit.

Pair it with the other Russian item CISA and the FBI have kept live since the spring: the ongoing campaign, run by actors tied to Russian intelligence, that phishes people out of their Signal and WhatsApp accounts. The encryption is not broken. Nobody cracked Signal. They get the target to hand over a verification code or link an attacker-controlled device, and walk around the crypto by owning the account. It has taken thousands of accounts, with the targeting aimed at officials, military personnel, political figures, and journalists.

Here is the Russian playbook, and the documented version of it needs no AI at all: unpatched known bugs, bad config, and a convincing lie. It works because it targets the trust that sits outside the model, outside the patch, outside the CVE -- the admin who never changed the default, the user who typed a code into the wrong box.


So line them up. A record patch release from a discovery pipeline Microsoft is increasingly running on AI. An agent that wrote to a symlink it had just identified as dangerous. A dev tool carrying disputed code its users could not evaluate in advance. A critical-infrastructure router exposed by a known bug or a default nobody changed. A Signal account lost to a convincing lie. Different altitudes, one failure repeated at every one of them: trust extended past the point where the surrounding controls can defend it.

The AI stories feel new. They aren't. They're the oldest failure in the field -- misplaced trust -- wearing this year's clothes and carrying a bigger blast radius, because an agent holding your credentials and a symlink bug can do more damage faster than a 1998 attacker with the same symlink bug ever could. The novelty is the scale, not the mechanism.

Which is why "patch faster" is the wrong lesson to walk away with, even in the week of the biggest patch drop on record. Patch the two exploited zero-days today -- that part is not up for debate, and the router advisory says the same about the known bugs it names. But faster patching is a treadmill, not a strategy. You cannot out-run a discovery engine that runs for the attacker too. A model update alone will not teach an agent to reliably tell code from instructions. No patch fixes a default credential the vendor left you to change. Those need a different move, and it is the one the advisory, the Friendly Fire authors, and the Claude Code argument are all pointing at from different directions: stop assuming the trust boundary holds. Assume it is already crossed and design for the blast radius -- least privilege that actually bites, credentials the agent cannot quietly spend, network paths you can see, an admin interface that was never on the internet in the first place. Patching keeps you alive. It does not fix the trust model, and this week the trust model was the attack surface at every altitude. It will be next week too.

More from this blog

T

The Digital First Responder | Systems Engineering & Mission Critical IT

23 posts

I'm Kerry Kier -- a systems engineer working at the intersection of infrastructure resilience, emergency communications, and practical AI deployment. I write about the things I'm actually building, breaking, and figuring out: self-hosted AI stacks, security architecture, DevOps pipelines, and what happens when mission-critical systems meet the real world. This isn't a thought leadership blog. It's field notes.