Zero Trust is a verb.
Go do it.

I have always been worried about how little organizations invest in their ability to prevent. Not detect, not respond, not report. Prevent. The unglamorous work of making sure the attack does not land in the first place.

Unglamorous, because prevention has a cruel property: the better you do it, the less there is to show. A blocked attack does not appear on a dashboard. A breach that never happened does not make a board slide. Nobody gets a budget increase for the incident that did not occur. So the work that reduces risk the most is the work that is valued the least, and over time organizations drift toward whatever produces a chart. An empty security dashboard is the best dashboard to have, and the hardest one to get credit for.

Instead, we have gotten used to notifications that our data has been stolen.

Now that I see what AI can do, I feel we are losing. Most organizations are far from prepared.

And not for lack of a plan. We have a plan. It has been on the table since 2010, it is well understood, and where it is applied it works. It is called Zero Trust.

The cybersecurity industry makes its money selling products, not helping you, the customer, do the work. There is no revenue in your firewall policy getting stricter or your admins going through a jump host. So the industry sells the box and calls it Zero Trust, and the work that actually reduces risk stays undone. Zero Trust is not a product. You cannot buy it, and nothing you install makes you Zero Trust.

The numbers say the same thing. When Gartner looked at large enterprises in 2023, fewer than one percent had a mature, measurable Zero Trust program, and the forecast was ten percent by this year. In Accenture's research, 88 percent of organizations call implementing Zero Trust a significant challenge. Sixteen years in, the strategy that everyone agrees on is the strategy almost nobody has finished.

What changed

Two things are happening at once, and they compound.

First, attackers are now measurably faster than defenders. In November 2025, Anthropic published the first documented intrusion campaign in which an AI agent did most of the work: a Chinese state-linked group used Claude Code to run reconnaissance, exploitation, lateral movement and exfiltration against roughly thirty organizations, with 80 to 90 percent of the operation executed without a human in the loop. It was caught partly because the model hallucinated, overclaiming access it did not have. That detection window is closing as the models improve. In September, Palo Alto Networks described a ransomware intrusion in which AI agents carried out every step, more than fifty techniques end to end, in under ten hours. Their estimate for a human crew doing the same work: about two weeks.

Meanwhile the defenders' clock is going the other way. Verizon's 2026 breach report found that vulnerability exploitation is now the number one way attackers get in, ahead of stolen credentials for the first time in the report's nineteen-year history, and that the median time to patch went up, from 32 to 43 days. Edge devices, the firewalls and VPN gateways that face the internet, are being exploited within days of a CVE going public. Forty-three days against a few days means the attacker wins by default.

Second, agents are popping up everywhere inside the enterprise. Not the three you onboarded through the identity team. The dozens that a developer wired into a pipeline, that a SaaS vendor switched on in your tenant, that a business unit bought with a credit card. They inherit the permissions of whoever launched them, they spawn subagents, they talk to each other, and most of them are on nobody's list.

Attackers are getting faster, and the number of things acting inside your network that you did not explicitly authorize is exploding. That combination is what worries me. Detection alone cannot keep up with a ten-hour intrusion executed by something that does not sleep. You have to prevent, and you have to have prevented before the intrusion starts.

What Zero Trust actually means on a Tuesday

I have spent years helping organizations move toward a Zero Trust environment, and the pattern is the same almost every time. The technology is rarely the bottleneck. The work is, and so is the willingness to do it.

The first thing we do together is look at the firewall policy. In nearly every engagement, there are rules with "any" in them that nobody can explain, written years ago for a migration that ended, kept because deleting them felt risky. I know of an any-any rule that survived three firewall generations and was still linked to a change ticket from an employee who left in 2016. That rule turned a firewall into a corridor, and the corridor was used. Making a policy strict means months of finding out what actually talks to what, and it is the single most valuable thing most organizations can do. When we finally turn on the strict policy and nothing breaks, people realize the change was far less risky than everyone assumed. Leaving the old rules in place was the bigger risk all along.

Then the jump host. Administrative access through one door, MFA, logged, nowhere else. No shared box between production and development, and no "air-gapped" OT network with a daily RDP session into it. We always meet resistance from the people who have had direct RDP to production for a decade. Six months later, nobody wants to go back.

Then SSO on everything. Every application, every admin console, every tool that the business swears is "just internal." Internal is where the attacker is standing after the first phishing mail.

Then patching, focused where the exposure is: internet-facing systems (web servers, VPN gateways, the security appliances themselves) and endpoints (laptops, phones). Those get patched the same day, not in the next maintenance window. The industry median is 43 days and the exploit arrives in a few. Same-day patching is only possible if you stop treating patching as a series of decisions and build a patching machine: a process that runs on its own, where the vendor advisory goes in one end and the patched system comes out the other, and where a human is only involved when something needs to stop it.

Then hardening what you run. Kubernetes can be made very strict: rootless containers, drop nearly every capability, read-only filesystems, no auto-mounted service account tokens, network policies that default to deny. Out of the box, a Kubernetes cluster is a flat network where a shell in one pod can reach every other pod in every namespace, and from there the node, and from the node the cloud account. I have not seen an organization close that on day one. I have seen many do it by month three once someone decided it mattered.

And underneath all of it: segment around what matters. Define the Protect Surface. Map the transaction flows in and out of it. Write policy for those flows and only those flows. Monitor. Maintain. Then take the next Protect Surface.

Not a project, a culture

The organizations I see struggle are the ones that ran a Zero Trust project, closed it, and moved on. A project has an end date. The policy drifts, the exceptions pile up, and two years later the firewall is back to "any." The other failure mode is the opposite: one enormous program with a large upfront budget, which gets cut somewhere between month twelve and month eighteen because it has not shown results yet. In Gartner's survey, more than a third of organizations that attempted Zero Trust suffered a failure that hurt the business. Both failure modes have the same cause: the work was treated as something you finish.

Zero Trust has to be culture. It is the default answer when someone asks for a firewall rule: which flow, from which Protect Surface, to which, why. It is the reflex when a new platform gets onboarded: SSO first, then we talk. It is the standing expectation that the policy gets stricter over time, never looser. It is network and security sitting in the same meeting with the same goal, instead of one optimizing for uptime and the other for control.

A project plan ends, and the policy ends with it. Habits in how the team makes decisions survive staff changes, reorganizations and the next technology wave.

We have seen this movie before

When cloud arrived, security was nowhere. Teams spun up environments in an afternoon, which was the whole point, and the network design that had taken years to get right on premises did not come along. Gartner predicted that through 2025, 99 percent of cloud security failures would be the customer's own doing, not the provider's. More than a decade in, many organizations still do not have proper firewalling and segmentation in their cloud environments. Flat networks, security groups that allow everything from everything, a management plane reachable from the internet.

Every new technology wave produces the same amnesia. The business sees the upside, security is told to keep up, and the fundamentals get skipped because they slow things down.

Agents are no different. Look at the arguments now being made that agents "break" Zero Trust:

So what should an agent look like in a Zero Trust environment? Its identity and permissions should be ephemeral, short-lived, and scoped to the subset of permissions it needs for this task, right now. Least privilege, and increasingly least agency: the smallest set of actions it is allowed to take on its own. Subagents get delegated credentials that are narrower still. High-consequence, irreversible actions get an approval gate. Everything leaves an immutable trail. And it lives inside a Protect Surface with defined flows, so when it goes wrong, the damage stays inside it.

This is Zero Trust, applied to a new kind of user.

The risk nobody puts on the slide

And yet, still today, this is what I hear in change boards and steering committees:

Every one of these weighs the risk of the change and the cost of the effort. None of them weighs the open risk you leave on the table by not doing it. A firewall patched once a year runs twelve months of known, published, actively exploited vulnerabilities on the most exposed device you own, in a year when exploiting exactly that device became the number one way in. An IPS in alert mode is a very expensive log file. Doing nothing is a decision, and in 2026 it is the most dangerous one available.

This has to change massively. The question in the change board should not be "what could go wrong if we do this?" It should be "what is going wrong right now because we have not?"

Where to start on Monday

Pick one Protect Surface. The one that would end up in the newspaper. Map its flows. Write the policy. Turn it on. Watch it. Then pick the next one. As John Kindervag puts it: it is not about where you start, it is that you start.

Give every agent the same treatment you would give a new contractor with a laptop: a short-lived badge, access to one room, and someone watching the door.

Patch the edge today, and start building the machine that does it without you tomorrow.

And stop calling it a project.

If you cannot do the heavy lifting yourself, find someone who will do it with you rather than sell you another box. That is why we started ON2IT: to help customers decide to do the right thing, and then take the work off their hands so it actually gets done.

FAQ