Zero trust verifies the device. It never asks what you meant.

A mature zero trust deployment answers one question extremely well: may this subject, on this device, in this context, access this resource. It does not answer a second question that most of the largest losses turn on: did the accountable human intend the act performed with that access.

Picture a company eighteen months into a zero trust programme that has actually gone well. Not a slide deck, a real one. Every application sits behind a policy enforcement point. Device posture is checked continuously and unmanaged devices get nothing. Standing privilege has been cut hard enough that people complained for a quarter and then stopped. Sessions are short. Conditional access policies are reviewed monthly. The programme is, by any honest internal assessment, a success, and the security team is right to be proud of it.

On a Tuesday afternoon a finance manager releases a payment of just over two million to a beneficiary added to the vendor master file the previous week. She is on her corporate laptop, which is fully patched and compliant. She authenticated that morning with a phishing resistant credential. Her session is valid, her network context is unremarkable, and her role carries exactly the entitlement required for this action and nothing more.

The policy decision point evaluates the request and permits it, and it is correct to do so. Every input is genuine. There is nothing anomalous to observe.

Twenty minutes earlier she was on a video call with the chief financial officer and two colleagues from group treasury, discussing the urgency of this payment. None of the three people on that call were real.

First, what zero trust actually got right

It is worth being precise about this before criticising anything, because the model deserves it and because a reader who has spent three years and a large budget on this architecture will reasonably stop reading if the piece opens with a cheap shot.

NIST Special Publication 800-207 formalised an insight that was correct and, at the time, genuinely contested: network location is not authorisation. The perimeter model treated the inside of a network as a trusted zone, which meant that a single compromise anywhere inside produced unbounded lateral movement. Everyone who has responded to an incident in a flat network knows exactly how that feels.

Zero trust replaced that with per request evaluation. Every access decision considers the subject, the device, the resource and the context, every time, with no standing trust derived from where the packet came from. The document defines the components carefully: a policy decision point that makes the call, a policy enforcement point that carries it out, and a set of inputs feeding the trust algorithm.

The results are real. Lateral movement is materially harder. Standing privilege shrank across the industry. Device health became a first class input rather than an afterthought. The federal memorandum M-22-09 pushed United States agencies onto a schedule, and CISA's Zero Trust Maturity Model gave organisations a way to talk about progress without pretending it is binary. This was one of the more successful pieces of security architecture evangelism in recent memory, and the reason it succeeded is that the underlying claim was true.

So the critique that follows is narrow. It is not that zero trust failed. It is that zero trust answers an access question, the industry has begun treating it as though it answers every question, and the gap between those two things is where the expensive losses now live.

What is the difference between access control and authorisation of an act?

These sound like the same thing and they are not, and pulling them apart is the whole intellectual content of this post.

Access control asks whether a principal may perform a class of operation on a resource. May this user read this bucket. May this service call this endpoint. May this role release payments. The answer is a function of identity, entitlement, device state and context, and it is evaluated before the operation proceeds.

Authorisation of an act asks whether a specific human intended a specific operation with specific parameters, at a specific moment. Did the accountable person mean to send this amount, to this beneficiary, now. That is not a property of the requester's environment at all. It is a property of a mind, and the only way to obtain evidence of it is to require the person to do something that only they can do, bound to the specific thing being decided.

The security guard and the signature

Here is the analogy that makes it stick. A building has an excellent security desk. Guards check identification against a live database, confirm the visitor is expected, verify the badge is not reported lost, and re-check at every internal door. This is a good access control system and it stops a great deal of harm.

Now a person walks up to the desk with entirely legitimate credentials, is admitted correctly, walks to the records room she is authorised to enter, and removes a file she is authorised to handle. The guard did everything right. The system worked exactly as designed.

Whether she was supposed to remove that particular file today, on the instruction of someone who was not who they claimed to be, is not a question the desk can answer. It is not a defect in the desk. Nobody at the desk knows the contents of a decision made in a meeting room upstairs, and no amount of improving the badge reader will change that. The control that addresses it is a signature on the release form, held by the records office, naming the file and the person who authorised its removal.

Zero trust is the security desk, and it is a very good one. What is missing is the release form.

Why does an adversary in the middle attack satisfy every zero trust control?

Because it satisfies them by construction, and this is the part worth working through slowly, because it is the cleanest demonstration that the gap is structural rather than an implementation weakness.

In an adversary in the middle phishing attack, the victim is directed to a reverse proxy that relays the genuine login page. The victim sees the real domain rendered through the proxy, enters real credentials against the real identity provider, and completes a real multi factor challenge. The identity provider issues a genuine session token, because everything it observed was genuine. The proxy captures that token.

Now trace what the policy decision point sees when the attacker uses the stolen session. The identity is real, because the token was properly issued to the real user. The authentication event in the log is real and shows a successful, policy compliant sign in. If the attacker replays from a similar geography, network context is unremarkable. Device posture signals, where they are bound to the session rather than to a live attestation from the endpoint, come along with it.

There is no anomaly, because nothing anomalous happened. The system is not being fooled. It is being told the truth about a set of facts, all of which are true, none of which are the fact that matters. We wrote about the mechanics of this attack class, and the industrial scale it now operates at, in the post on session theft.

The same shape appears in the other big cases. The Scattered Spider intrusions that hit major hospitality operators in 2023 began with social engineering of a help desk into performing a credential reset, which produced a perfectly compliant, entirely legitimate identity for the attacker to use. MGM Resorts disclosed an impact in the region of one hundred million dollars in its own filings. No control was bypassed. A control was correctly operated on the basis of a false premise. We covered that pattern in the help desk reset post.

And in the deepfake payment cases, there is not even a compromise to detect. In the widely reported Arup incident, a finance employee moved roughly twenty five million dollars across fifteen transfers after a video call on which the other participants were synthetic. Her device was hers. Her session was hers. Her authority was hers. Reported deepfake enabled fraud losses reached around one and a half billion dollars in 2025 according to research compiled by Surfshark, against business email compromise losses of three billion and forty six million reported to the FBI's Internet Crime Complaint Center for the same year. Essentially none of that was stopped by a posture check, because essentially none of it involved a posture failure.

Mapping the tenets: what each one establishes, and what it does not

SP 800-207 sets out seven tenets. Each is sound. None of them, individually or together, establishes intent. Setting them side by side is the fastest way to see that the gap is architectural rather than a matter of maturity.

Read the third column downward. Every entry is some version of the same sentence. That repetition is not a rhetorical device, it is the finding: the architecture is internally consistent and consistently silent on one question.

We call this failure Session-Inherited Authorization, and the fact that it appears inside the best available access architecture rather than in spite of it is exactly why it deserves a name. It is catalogued alongside thirteen others in the Identity Failure Map.

Does continuous access evaluation close the gap?

It helps meaningfully with a different problem, and it is worth being precise about which.

Continuous access evaluation, and the shared signals work in the OpenID Foundation that generalises it, exists so that a change in circumstances propagates to a live session rather than waiting for token expiry. If an account is disabled, if a device falls out of compliance, if a risk signal fires, the session can be terminated in near real time. Before this, a stolen token was good until it expired, which could be an hour of unconstrained activity.

That is a genuine improvement and every organisation should have it switched on. But notice what it re-evaluates: posture and principal state. It asks, again, the same access question, more often. If nothing about the posture has changed, and in a session theft nothing has, continuous evaluation returns the same answer continuously.

Risk based step up authentication is closer to the mark, and it is the control most people reach for when this gap is described. When risk scores rise, prompt for another factor. Two problems. First, it is triggered by detected risk, so it inherits every weakness of the detection, and in the cases that cost the most there is no risk signal to detect. Second, and more fundamentally, a step up prompt asks the user to prove who they are again. It does not ask them to attest to what they are doing. A user who is re-prompted mid session will approve, because they are in the middle of their work and the prompt does not tell them which act it belongs to. We took this apart in detail in passkeys prove the login, not the transaction.

This is the distinction to hold on to: re-authentication proves the principal again. It does not bind anything to the act. Those are different cryptographic operations with different security properties, and conflating them is how organisations end up believing they have addressed a risk they have not touched.

How do you add intent to a zero trust architecture?

You do not replace anything. You add a claim, and you require it for a small, deliberately chosen set of operations.

The policy decision point is already the right place for this. It already evaluates a set of claims about identity, device and context before permitting an operation. The proposal is to add one more claim to that set, available only for designated high consequence actions: a receipt proving that the accountable human signed this exact request payload, on a device they hold, within the last few minutes.

In policy terms it looks like this. The syntax below is illustrative rather than any specific vendor's language, but it maps cleanly onto how conditional access and modern policy engines already express requirements.

policy "treasury.release.over_100k" {
  resource = "treasury.payments/release"
  effect   = "allow"

  # Everything zero trust already gives you. Necessary.
  require identity.authenticated       == true
  require identity.assurance           >= "phishing_resistant"
  require device.compliant             == true
  require device.managed               == true
  require network.risk                 == "low"

  # The claim the access layer cannot produce on its own. Also necessary.
  require intent.receipt.present       == true
  require intent.receipt.payload_hash  == sha256(request.body)
  require intent.receipt.signed_by     == identity.subject
  require intent.receipt.age_seconds   < 120
}

The line that does the work is the payload hash comparison. The receipt is not a general assertion that the user is present and awake. It is a signature over the bytes of this specific request, so it cannot be replayed against a different payment, cannot be harvested in advance, and cannot be produced by anyone who does not hold the enrolled device. A stolen session yields no valid receipt, because the session is not the key.

On the enforcement side, the check is local and requires no call to us:

def evaluate_intent(request, receipt, published_keys):
    # 1. The receipt must cover exactly this request, byte for byte.
    if receipt.payload_hash != sha256(canonical(request.body)):
        return DENY("receipt does not match this payload")

    # 2. The signature must verify against the published key. No callback.
    if not ed25519_verify(published_keys[receipt.key_id],
                          receipt.bytes, receipt.signature):
        return DENY("signature invalid")

    # 3. The signer must be the accountable subject, not merely someone.
    if receipt.subject != request.identity.subject:
        return DENY("signed by the wrong human")

    # 4. Freshness, so a receipt cannot be banked and reused later.
    if now() - receipt.issued_at > 120:
        return DENY("receipt stale")

    return ALLOW(evidence=receipt)

Note the fourth line of the first block and the second step of the second. Verification happens against a published key with no network call to the issuer, which means the control keeps working when we are unreachable and cannot be undermined by a compromise of our infrastructure. That property matters more than it first appears: a security control that introduces a new availability dependency into the payment path is a control that will eventually be switched off during an incident.

What the CISO actually gets from this

Three things that continuous evaluation alone cannot provide, and it is worth naming them separately because they land with different people.

The first is prevention for a specific loss class. The attacker with the session, the deepfake on the call, the agent in the browser, none of them hold the enrolled device, so none of them can produce the receipt, so the designated actions do not execute. This is deterministic rather than probabilistic, which is a different kind of claim from anything a risk score can make.

The second is evidence that survives the incident. When the post mortem asks who authorised the transfer, the current best answer in most organisations is a log entry showing which policy allowed it and which session made the request. That is an answer about the system. A receipt is an answer about a person, verifiable by a third party who does not trust your logging pipeline, which is precisely what an auditor, an insurer or opposing counsel is asking for. The audit trail design post covers what makes this class of evidence hold up.

The third is a defensible position on scope. "We require a human signature on payments above this threshold, on privileged role grants, and on bulk data egress" is a sentence a board understands, an insurer can price, and a control tester can verify. It maps cleanly onto framework language about transaction authorisation, and it does not require claiming that zero trust failed.

Does zero trust cover AI agents?

It covers their access. It does not cover their authority, and the difference is about to become expensive.

Vendors are adding agent access features to existing posture models, which is a sensible first move: give the agent an identity, evaluate it like any other principal, apply least privilege. That handles the question of whether this agent may call this endpoint.

It leaves the question that actually matters in a dispute, which is whether a human authorised this agent to do this, within what scope, and for how long. A policy engine evaluating an agent's request sees a well formed principal with valid credentials and appropriate entitlements, which is exactly what a hijacked agent also looks like, because prompt injection does not change the agent's identity or its posture. It changes its objective.

The composable answer is the same shape as before: the agent presents a delegation chain that terminates in a human signature, and the policy engine verifies the chain offline as one more claim. We set out how those chains work, including scope narrowing and depth limits, in the delegation chain post, and what it means to be able to enumerate live authority in the authority graph. You can see a human gated action running in the agent authorisation inbox.

What this does not fix

The limits here are real and a CISO will find them within ten minutes of thinking about deployment, so they belong in the post rather than in a footnote.

A signature attests intent, not judgment. If the finance manager on the deepfake call had held an enrolled device and signed the payload, the signature would be perfectly valid and the money would be perfectly gone. This control stops the unauthorised act. It does not stop a deceived human who genuinely means to act. What it does do is force the fraud to survive contact with a moment where the actual amount and the actual beneficiary are displayed on a separate device, which is a materially better position than an approval buried in a browser session, and it produces evidence about who was deceived. That is a real improvement and it is not the same as prevention.

Friction is the entire design problem. Every signature is an interruption. Require one on too many operations and people will batch their work to avoid the prompt, ask colleagues to approve things for them, or press the button reflexively without reading, which is worse than not having the control because it manufactures evidence of an intent nobody formed. The art is choosing a small set of actions where the consequence justifies the interruption. In most organisations that is a handful, not a hundred.

A compromised enrolled device defeats it. If the attacker holds the device and can unlock it, they can sign. Device binding raises the cost of the attack substantially and changes it from remote and scalable to local and targeted, which is the point, but it is not a claim of invulnerability.

Enrolment is the trust bottleneck. Someone, once, has to establish that this key belongs to this human. Everything downstream inherits the quality of that moment, which is why attacks on the enrolment step matter so much and why enrolling at least two authenticators per person is not optional in practice.

This is a composition, not a product replacement. Manav does not replace a policy engine, a network access product, or an identity provider, and any pitch that says otherwise should be treated with suspicion. The receipt is a claim your existing policy engine consumes. Native policy engine integrations are not something we ship today, so current deployments obtain the receipt in the application and pass it as a claim. The mechanics are in the developer documentation.

What to do this week

1. Write down the ten actions in your organisation that would hurt most if performed by someone holding a valid session. Payment release above a threshold, vendor bank detail changes, privileged role grants, bulk data export, production database destruction, credential resets. Ten, not fifty.
2. For each one, ask what your policy engine currently evaluates, and write the answer in the language of the third column of the table above. The exercise takes an hour and usually produces silence.
3. Take one past incident, or one industry incident you follow, and list which of your zero trust controls would have been satisfied at the moment of loss. This is the single most persuasive artifact you can bring to an executive conversation, because it is specific and it is not hypothetical.
4. Check whether your step up policies re-authenticate or attest. If the prompt does not display what is being authorised, it is proving the principal, not the act. Most do not display it.
5. Turn on continuous access evaluation if you have not, because it genuinely helps with the adjacent problem and there is no reason to leave it off.
6. Ask your network access and identity vendors directly whether their policy engine can require an action bound claim, and what format it would accept. The answers will tell you a lot about where the category is going.
7. Decide, on paper, what evidence you would want to have in hand the morning after a two million pound transfer turns out to be fraudulent. Then check whether your architecture would produce it.

Frequently asked questions

Does zero trust stop business email compromise and deepfake fraud? No, and it was not designed to. Zero trust decides whether a subject and device may access a resource. It does not prove the human intended the specific act performed with that access. In business email compromise and deepfake authorised payments, the identity, device and session are all genuine, so every policy input is satisfied and the fraudulent action is permitted correctly.

What is the difference between access control and authorisation of an action? Access control asks whether a principal may perform a class of operation on a resource, and it is answered from identity, entitlement, device state and context. Authorisation of an action asks whether a specific human intended a specific operation with specific parameters at a specific moment. The second is not an observable property of the requester's environment, so a policy engine cannot derive it from the inputs it has.

Does continuous access evaluation fix this? No. Continuous access evaluation propagates changes in posture and principal state to live sessions, which is a real improvement over waiting for token expiry. It re-asks the access question more often. In a session theft nothing about the posture has changed, so continuous evaluation keeps returning the same permit decision.

Is risk based step up authentication enough? It helps, with two limits. It fires on detected risk, so it inherits every weakness of the detection, and the costliest cases produce no anomaly to detect. More fundamentally, a step up prompt proves the principal again rather than binding anything to the act, and a user prompted mid workflow will approve without knowing which operation the prompt belongs to.

How do you add transaction signing to zero trust? Add an intent claim to the policy decision point for a designated set of high consequence actions. The claim is a receipt containing a signature over the hash of the exact request payload, produced on the accountable human's enrolled device, with a freshness bound. The enforcement point verifies it against a published key with no callback, alongside the identity and posture checks it already performs.

Does zero trust cover AI agents? It covers their access, by treating an agent as a principal with an identity and entitlements. It does not cover their authority. A hijacked agent has the same identity and posture as a well behaved one, because prompt injection changes the objective rather than the credentials, so the policy engine sees nothing wrong. Verifying a delegation chain that terminates in a human signature is what addresses that.

Are you saying zero trust was a mistake? Not at all. The core claim, that network location is not authorisation, was correct and its adoption made lateral movement much harder. The critique is narrow: the architecture answers an access question well, and the industry has begun treating it as though it answers every question. The intent layer composes with zero trust rather than replacing any part of it.

Sources

1. NIST Special Publication 800-207, Zero Trust Architecture, including the seven tenets and the policy decision point model. csrc.nist.gov/pubs/sp/800/207/final
2. CISA, Zero Trust Maturity Model. cisa.gov/zero-trust-maturity-model
3. US Office of Management and Budget, Memorandum M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles. whitehouse.gov/omb memoranda
4. FBI Internet Crime Complaint Center, 2025 Internet Crime Report, business email compromise losses and complaint counts. ic3.gov annual reports
5. Surfshark research on reported deepfake enabled fraud losses. surfshark.com/research
6. MGM Resorts International, Form 8-K disclosure of the 2023 cybersecurity incident and its financial impact. SEC EDGAR filings
7. Microsoft Security, research on adversary in the middle phishing kits and session token theft. microsoft.com/security/blog
8. OpenID Foundation, Shared Signals Framework and Continuous Access Evaluation Profile. openid.net/wg/sharedsignals

Zero trust made the network honest. It left the act unattested. The next control is not another posture check, it is a signature on the thing that actually moves the money.