The two biggest security stories of mid-2026 are the same mistake, one abstraction layer apart. A firewall got rooted because an authentication portal was reachable from the open internet. An AI agent got robbed because it installed an unsigned skill from an open marketplace. Different decade, different stack, identical failure: no provenance, no least privilege, no change control.
I have spent seventeen years securing enterprise networks. Watching the AI-agent world melt down this year feels exactly like watching a misconfigured firewall get owned, because it is the same thing. The lessons the network-security trade paid for in blood over twenty years are the lessons the AI world is now learning live, at speed, in public. This post is the translation, written by someone who has worked both sides of the line.
What actually happened on the firewall side
In May 2026, Palo Alto Networks disclosed CVE-2026-0300: a buffer overflow in the PAN-OS User-ID Authentication Portal that lets an unauthenticated attacker run code as root by sending crafted packets. CVSS 9.3. It affects PA-Series and VM-Series firewalls running that portal, and Unit 42 confirmed exploitation in the wild by a likely state-sponsored cluster that injected shellcode into an nginx worker process.
The detail that matters is not the overflow. It is the precondition. The vulnerability only bites when the Authentication Portal is exposed to untrusted networks. Palo Alto’s own guidance is blunt: restrict the portal to trusted internal IPs and the risk collapses. A companion flaw, CVE-2026-0257 in GlobalProtect, was reassessed to critical once active exploitation confirmed an auth bypass was real rather than theoretical.
So the box was vulnerable because of a code defect, but it got rooted because somebody put a management-adjacent service on the public internet and nobody flagged it as a change. That is not a Palo Alto problem. I have written that exact finding in audit reports across a dozen vendors. The appliance is just where it surfaced this time.
What actually happened on the AI side
Around the same window, security researchers exposed a supply-chain campaign on the skill marketplace for an open AI-agent platform. Koi Security named it ClawHavoc in February 2026. The numbers are the story: at least 1,184 malicious skills planted across a handful of publisher accounts, an estimated 300,000 agent users in range, and a macOS payload that researchers tied to the Atomic macOS Stealer family, lifting keychains, SSH keys, browser credentials, and crypto wallets.
The qualifying detail, again, is not the malware. It is the publishing bar. To upload a skill that an agent would fetch and run, an attacker needed a GitHub account at least a week old. No code review. No signing. No provenance check between “a stranger wrote this” and “your agent now executes it with your permissions.” The marketplace optimised for frictionless contribution and treated trust as somebody else’s problem.
An AI skill is just code that runs in your context. A marketplace that ships unsigned code from anonymous authors directly into an executing agent is a software repository with the safety catch filed off. We have seen this film before. It was called the early package-registry era, and npm, PyPI and the rest spent years bolting on the controls that were missing from day one.
Why I call them the same mistake
Strip both incidents down to the decision that caused them and they converge. Each one trusted something it had no business trusting, gave that thing more reach than it needed, and let it change the running system without anyone reviewing the change. The abstraction layer is different. The fault line runs through the same three controls.
| Failed control | Firewall side (CVE-2026-0300) | AI-agent side (ClawHavoc) |
|---|---|---|
| Provenance & trust | An auth portal accepting packets from any untrusted source on the internet | Unsigned skills from anonymous publishers, no review between upload and execution |
| Least privilege | Exploit lands as root, full control of the appliance, no blast-radius limit | Skill runs with the agent’s full identity: keychains, SSH keys, wallets |
| Change control | Exposing a management-adjacent service was never reviewed as a change | Adding a third-party skill is a silent dependency change nobody approves |
| Exposure | Reachable from the public internet by design | Reachable through a public marketplace by design |
| Detection | nginx-worker shellcode went unnoticed until vendor disclosure | Theft ran for weeks before researchers, not victims, raised the alarm |
Read that table top to bottom and the appliance and the agent stop looking like separate problems. The new technology did not invent a new way to fail. It rediscovered the oldest one and handed it a faster engine.
The control the network world learned the hard way: provenance
Provenance is knowing where a thing came from and whether you should trust it before you let it act. Network security learned this lesson the expensive way. We stopped trusting traffic because it arrived on the inside interface. We stopped trusting a device because it sat in the right VLAN. Zero trust is a twenty-year apology for assuming that location implied trust.
The AI-agent world is making the identical assumption with a fresh coat of paint. “It is in the official marketplace, so it is fine.” “It has stars, so it is fine.” A marketplace listing is a location, not a trust decision, the same way an internal IP was a location and not a trust decision. The fix is the same fix: verify the source, require signing, and treat anything unverified as hostile until proven otherwise. If you want the deeper version of this argument for AI specifically, I wrote it up against the framework in the OWASP LLM Top 10 for 2026, where prompt injection (LLM01) and excessive agency (LLM06) are the same provenance-and-privilege failure dressed for the model layer.
The control both worlds keep skipping: least privilege
Least privilege answers one question: when this thing is compromised, and it will be, how much can it touch? On the firewall, the answer was “everything,” because the exploit landed as root. On the agent, the answer was also “everything,” because a skill inherits the full identity of the agent that loads it, and that agent was carrying keychains and wallet access it never needed for the task at hand.
I have spent a career arguing that a firewall rule should permit the narrowest source, destination, and service that makes the business work, and not one port more. The reason is not tidiness. It is that the rule will eventually be wrong, or abused, and the only thing standing between “wrong” and “incident” is how little that rule was allowed to reach. An AI agent needs the same discipline. A skill that summarises documents has no business holding wallet keys. Scope the agent’s credentials to the task, default-deny the tools it can call, and require explicit confirmation for anything destructive. This is exactly the thinking I applied across hundreds of firewall audits, redrawn for a new surface, and I lay out the firewall version in my piece on firewall change automation.
The control that makes the other two real: change management
Provenance and least privilege are static design choices. Change management is what keeps them true after launch, when the pressure is on and the system drifts. Both 2026 incidents are change-management failures dressed as technical ones. Exposing that auth portal was a change nobody reviewed. Installing that skill was a dependency change nobody approved.
Here is the uncomfortable parallel. The network industry already knows that change control on paper does not survive contact with operational reality, which is the entire reason I built a platform to enforce it on firewalls rather than trust the weekly change board. The AI-agent industry has not even reached the paper stage. There is no change board for “my agent added a new skill at 2am.” A team running autonomous agents in 2026 has less visibility into what their software is executing than a 2006 network team had into its firewall ruleset, and that should frighten anyone who has lived through a real audit. For the wider Mittelstand readiness gap this opens up, see why German SMEs are dangerously unprepared for NIS2.
What to actually do, this quarter
The translation is only useful if it changes Monday. Whether you run firewalls, AI agents, or both, the same short list applies. None of it is novel, which is the point.
- Inventory your exposure. List every management-adjacent service reachable from an untrusted network, and every third-party skill, model, or tool your agents can load. You cannot defend what you have not enumerated.
- Require provenance. Restrict the firewall portal to trusted IPs. Allow only signed, reviewed skills from sources you have vetted. Treat a marketplace listing as a claim, not a credential.
- Cut privilege to the task. Patch CVE-2026-0300 and friends, then scope what survives. Scope agent credentials and tool authorisations the way you scope a firewall rule: narrowest thing that works, default-deny everything else.
- Make change visible. Every config change and every new dependency should generate reviewable evidence. If you cannot answer “what changed, who approved it, and why” in minutes, your audit trail is decorative.
Map this against any framework you answer to and it lands in the same controls: ISO 27001, NIS2, DORA, BSI IT-Grundschutz. They all demand provenance, least privilege, and evidence of change. The frameworks were right; we are just applying them to a layer that did not exist when they were written. If you want the broader European consulting context, I cover it in my note on AI security consulting for European enterprises, and the detection side in AI threat detection strategies for CISOs.
Why a network security background is the right lens
I am not an AI researcher who picked up some security on the way. I came the other direction: from PAN-OS, Check Point, Cisco and Fortinet, from OT segmentation and ISO 27001 audits, into AI security. That order matters, because the AI-agent failures of 2026 are not novel AI problems. They are classic infrastructure problems wearing a model on top, and the people best placed to see that are the ones who already paid for the lesson once.
The firewall world spent two decades learning that trust must be earned, privilege must be minimised, and change must be controlled. The AI world is learning it now, faster and more publicly, with the same three controls written in the post-incident report every single time. You do not have to learn it the way we did. You can borrow the answer. I have shipped production AI under exactly this discipline, which I wrote up in the lessons from building RogueAI.
If you are deploying AI agents and your security model has not caught up with what they can execute, that gap is reviewable now rather than after an incident. I run engagements that translate enterprise network-security discipline onto AI workloads: provenance, least privilege, and change control built to survive a real audit. Request a review. See also FwChange.com for firewall change automation and RogueAI.de for the production AI portfolio.