Zero trust is a security model in which no person, device, system or AI agent is trusted by default, and every request for access is verified explicitly, limited to what is needed and granted on the assumption that a breach has already happened. It is usually sold as technology. In practice it is a set of leadership decisions about what the organisation trusts, why, and who answers for that trust when it fails.
The concept appears under several names: zero trust architecture, the zero trust security model, “never trust, always verify”, perimeterless security and identity-first security. All of them describe the same shift: trust is no longer granted by being inside the network, but earned request by request.
The standards already place this with leadership. NIST Special Publication 800-207, Zero Trust Architecture (2020), defines zero trust as moving defences away from static network perimeters and states that no implicit trust is granted to users or assets based solely on their network location. The NIST Cybersecurity Framework 2.0 (2024) makes Govern a core function, putting cybersecurity strategy, roles and oversight with the organisation’s leadership. ISO/IEC 27001:2022 requires top management to demonstrate leadership of the information security management system.
Adoption is broad, but shallow. Sixty-three per cent of organisations have fully or partially implemented a zero-trust strategy, yet for most that strategy covers half or less of their environment and mitigates a quarter or less of enterprise risk (Source: Gartner, State of Zero-Trust Adoption Survey, 2024). Meanwhile, the number of identities to govern is growing fastest outside the workforce: machine identities now outnumber human identities by 82 to 1 (Source: CyberArk, 2025 Identity Security Landscape, 2025).
This analysis draws on a recent conversation with Nicolas Blank, CTO of NBConsult and a co-author of Microsoft’s Zero Trust adoption framework. We have translated his argument into executive decisions.
Why do zero trust programmes fail before the technology arrives?
Zero trust programmes fail early because they start with controls before anyone has decided what the organisation is trying to protect and who owns that decision. Blank’s case is that most security programmes break down at the point of decision-making, not implementation. Organisations buy tools and switch on policies before the leadership team agrees on intent.
Controls then multiply, friction rises and risk barely moves. As the discussion puts it, a product is not a process: tools can only reinforce decisions an organisation has already made. Where those decisions do not exist, technology fills the gap with rules nobody owns.
Blank also stresses emotional buy-in, built through everyday analogies. You do not hand your car keys to just anyone; you know who you trust and why. Organisations, by contrast, accumulate access through convenience rather than intention.
What does “assume breach” mean for the executive team?
“Assume breach” means planning on the basis that an attacker is already inside, so the question becomes how far they can go and how quickly the organisation will notice. For the executive team, it replaces the comfortable question “are we secure?” with a harder one: “if this account were compromised today, what could it reach?”
It forces decisions on which data and processes matter most, how much disruption containment may cause, and who has authority to act. Blank’s shorthand for the modern reality is blunt: “The perimeter is on everything.” The speed at which those decision points can be exploited is the subject of AI-Speed Cyberattacks: What the Board Must Decide Before the Incident.
How do AI agents widen the identity surface, and who owns the trust they are given?
AI agents widen the identity surface because each one is a new identity that holds permissions, acts on data and makes requests. An agent that can update a record or trigger a payment is exercising delegated trust, which must be defined, limited and owned.
Blank’s position is that accountability remains human even when the action is automated. Leadership must set the limits within which AI can act, the guardrails on its behaviour and the ownership model that applies when outcomes go wrong. Trust in an agent should be conditional and contextual, never absolute. The ISO/IEC 42001:2023 requirement to assign roles, responsibilities and authorities for AI systems points the same way. We set out the governance model in Who Owns the AI Agent When It Breaks?
The AIPEX view: zero trust is a delegation of authority, not a security purchase
At AIPEX we treat zero trust as a delegation of authority that the executive team designs and the board approves. The security function implements it; it cannot decide it. Blank’s warning that security breaks down the moment responsibility is outsourced applies inside the organisation as much as to vendors: handing the whole question to the CISO is also outsourcing.
The practical instrument is a trust register: a board-approved record of what the organisation trusts, on whose authority and for how long.
| Trust decision | Accountable owner | What the board should see |
|---|---|---|
| Which data and processes are critical | CEO and executive team | A ranked list, reviewed annually |
| Who and what may reach them | Named business owner per asset | Privileged access counts, human and machine |
| What AI agents may do unaided | Business owner of each agent | An inventory of agents and their permissions |
| How much disruption containment may cause | COO or CFO | Pre-agreed limits, tested in an exercise |
| Which third parties hold standing access | Contract owner | Access reviewed at each renewal |
Guardrails come before controls. Without these decisions, zero trust becomes an expensive project covering half the estate.
What should the board ask before approving the next zero trust investment?
The board should ask whether the trust decisions have been made, before it asks what the technology will cost:
- What do we trust by default today, and when did anyone last check whether those reasons still hold?
- For our five most critical assets, who is the named owner of access decisions?
- How many AI agents and machine identities hold access to sensitive data, and who owns each one?
- If a senior executive’s account were compromised this morning, what could it reach?
- What proportion of our environment and our enterprise risk does the current programme actually cover?
Several answers depend on data ownership, which is why we argue in Privacy and Security Are One Risk that data governance belongs to the board.
If no one at executive level owns the trust decisions your AI agents now depend on, that is the gap to close first. A Fractional Chief AI Officer can hold AI and security trust decisions under one accountable executive, without a full-time hire. The Executive Strategy Day builds the first version of your trust register: what you trust, who owns it and what your AI agents are allowed to do.
Frequently asked questions
Is zero trust a technology or a leadership responsibility?
Zero trust is enforced by technology but decided by leadership. Executives must define what the organisation trusts, why, and who is accountable when that trust fails; tools can only reinforce those decisions. For a full explanation, see Zero Trust Is a Leadership Decision, Not a Technology Project →
Why do AI agents create new zero trust risks?
Each AI agent is a new identity with permissions to read data and take actions, so every agent widens the surface that must be verified and limited. Accountability for what an agent does stays with a named person, not the system. For a full explanation, see Who Owns the AI Agent When It Breaks? Delegated Authority for Boards →
What is a trust register?
A trust register is a short, board-approved record of what the organisation trusts, on whose authority and for how long, covering critical assets, AI agents and third-party access. It turns zero trust from a security project into a set of owned executive decisions. For a full explanation, see Zero Trust Is a Leadership Decision, Not a Technology Project →