Zero Trust Is an Operating Model, Not a Product

Perimeter security made sense when applications lived in a data centre and employees worked from offices. That arrangement has gone. Workloads span several clouds and dozens of SaaS applications, people work from anywhere, suppliers hold credentials into core systems, and AI agents now act on those systems with a degree of autonomy. Zero trust, summed up as never trust, always verify, assume breach, is the right model for this reality. The problem is what organisations do with it.

Most buy it. This article argues for a zero trust operating model instead: a change to how identity, access and infrastructure are run every day, with owners, routines and measures, delivered in waves over several years. The tooling matters, but it is the smaller part of the work.

The product trap

Zero trust has become a labelling exercise. It is easy to conclude that an identity platform, a network access gateway and an endpoint detection suite add up to a zero trust organisation. They do not, any more than a gym membership makes someone fit.

The pattern in publicly reported breaches is consistent. Attackers obtain a valid credential, find that it carries more privilege than its owner ever needed, and move sideways through an estate that owned perfectly good security tooling. The tools were in place. The discipline around them was not.

A product can enforce a policy. It cannot decide who should have access to what, keep that decision current as people change roles, or persuade a business unit that its administrators no longer hold permanent rights. Those are operating questions, and they are where zero trust programmes succeed or stall.

Identity is the perimeter now

If the network no longer marks the boundary, something else must. That something is identity. A credential is the one asset that opens all the others, which is why phished, stolen, reused and over-privileged accounts feature so often in incident reports.

Money spent on advanced threat detection is partly wasted if an attacker can simply log in with a valid password.

Yet in many organisations identity and access management is still a patchwork: several directories, manual provisioning by ticket, and access rights that accumulate like sediment. Four forces are breaking that arrangement.

• Distributed work. Employees, contractors and partners connect from networks you do not manage to applications that never touch your infrastructure.
• Joiner, mover, leaver decay. Access builds up as people change roles. Reviews regularly find staff holding rights from previous jobs, and accounts that outlived their owners.
• Supplier access. Third parties hold standing credentials into your systems, often with less scrutiny than your own staff receive.
• Regulatory expectation. Regimes such as GDPR, NIS2 and, for EU financial entities, DORA push organisations to show that access is justified, reviewed and minimal, not merely to list who has it. Confirm the specific obligations that apply to you with counsel.

The target state treats identity as a governed lifecycle instead of an administrative chore. Provisioning and deprovisioning are driven by HR events. Roles are defined, and certified periodically by the people who understand the work. Phishing-resistant authentication is the norm, not the exception. Privileged access is granted just in time, with approval and expiry.

AI agents and other non-human identities

Human accounts are the smaller part of the problem. Service accounts, API keys, workload identities, automation scripts and integration tokens outnumber people in most estates, and they usually receive far less governance. Many have no named owner and never expire.

AI agents raise the stakes. An agent that reads a mailbox, queries a finance system and raises a purchase order is an actor with credentials and the ability to cause real effects. If it borrows a person's full permissions, or runs under a shared service account, you cannot limit what it does, attribute what it did, or switch it off cleanly.

The discipline applied to people should apply to every non-human identity.

• Inventory and ownership. Every service account, key and agent is recorded, with a named human owner accountable for it.
• Its own identity. Each agent has a distinct identity, not a borrowed user login, so its actions can be logged and attributed.
• Scoped, short-lived credentials. Permissions match the task, tokens expire quickly, and secrets rotate automatically.
• Approval for consequential actions. Payments, deletions, external messages and access changes pass through a person or a policy check.
• A tested off switch. Revoking an agent's access is a rehearsed procedure, not an improvised one.

Organisations moving agentic AI from pilots to production will find this is the control that lets security say yes.

What a zero trust operating model changes

Four things change in how the estate is run.

• Identity becomes the control plane. Every user, device, service and agent has a verified identity, and access decisions are evaluated continuously using context such as device health and location, not granted once at login.
• Least privilege is enforced, not aspirational. Standing administrative access is removed in favour of just-in-time elevation with approval and expiry.
• The network stops implying trust. Being inside grants nothing. Every connection is authenticated and authorised per session.
• Blast radius is designed, not discovered. Segmentation ensures that a compromised laptop or supplier account reaches a contained slice of the estate.

Underneath those sit the operating elements that products cannot supply: a named owner for each control, a cadence for access reviews, an exceptions process in which every exception expires, and a small set of measures reported to the executive team. Useful measures include the number of standing privileged accounts, the time taken to remove a leaver's access, and the count of non-human identities without an owner.

Where to start: waves, not a big bang

Zero trust fails as a big-bang project and succeeds when adopted in deliberate, measured waves across several years. Each wave reduces risk on its own.

• Wave one: identity hygiene. Consolidate directories, enforce multi-factor authentication everywhere, remove orphaned accounts, and automate leaver processing from the HR system.
• Wave two: privileged access. Eliminate standing administrator rights, vault and rotate secrets, and bring service accounts and agents into the inventory.
• Wave three: protect the crown jewels. Identify the handful of systems whose loss would stop the business, and segment them first.
• Wave four: continuous verification. Extend per-session, context-aware access across the remaining estate and retire implicit network trust.
• Throughout: test it. Exercise the controls through adversarial testing, including red teaming of AI systems, and feed the findings back into the plan.

Sequence by risk, not by what a supplier's reference architecture shows first.

Common questions

How long does zero trust take to implement?

There is no finish line, because it is a way of operating and not an installation. Most organisations should expect a multi-year programme, with the first identity wave showing results within months.

Do we need to replace our existing security tools?

Usually not at the outset. Many organisations already own capable identity, endpoint and network tooling that is only partly configured. Start by using what you have properly, then fill real gaps once the access model and ownership are clear.

How should we manage identities for AI agents?

Treat each agent as a distinct, owned identity with narrowly scoped, short-lived credentials and full logging. Require approval for consequential actions and rehearse revocation. Avoid letting agents inherit a person's full permissions, which makes both control and audit far harder.

Where Ganexa can help

Ganexa helps organisations design and run zero trust as an operating model sized to their risk, not to a vendor diagram. Our Cybersecurity for the AI Era service covers identity, privileged access and the security of AI systems and agents, our AI governance and compliance work ties controls to the obligations you must evidence, and a fractional CTO or CIO can provide senior ownership where it is missing. To talk through your starting point, book a free consultation.