NIST makes dual authorisation for AI agents concrete: separate the agent, the policy layer and the human approver

On 27 October 2026 NIST published design tenets for agent identity that make dual authorisation concrete: an autonomous AI agent may prepare an action, but authorisation belongs to a separate, deterministic policy layer, and above recorded risk thresholds to a human approver with their own identity. The agent must never set its own authority, approval or logging.

In its design tenets for agent identity, the National Institute of Standards and Technology describes that agents should have their own, cryptographically verifiable identity that is distinct from human identities, that delegated authority should decrease, that agents should not receive permanent rights, and that authorisations should be temporary, purpose-bound and revocable. Separation of duties should prevent any single agent combining conflicting privileges.

These tenets build on earlier NIST material, including the concept paper on agent identity and authorisation and the summary of comments received, which argue for a logically separated governance component to enforce authorisation consistently with zero-trust principles. In our assessment the real shift is that separation of duties is no longer an extra review step but an architectural question: agent identity, policy decision and human release must each be independently verifiable.

What exactly does NIST establish about agent identity and separation of duties?

NIST describes that an AI agent has its own identity and that its authorities should be temporary and revocable. Our analysis translates this into a separate component that takes the authorisation decision: the agent reasons and prepares, but does not decide on its own access. That is the difference from common practice, in which an agent runs with broad, fixed rights.

Concretely, NIST names these coherent building blocks:

• a cryptographically verifiable agent identity, distinct from human identities;
• decreasing, purpose-bound delegated scopes instead of permanent authorities;
• signed mandates that record on whose behalf the agent acts and what it may not do;
• a deterministic policy layer that checks identity, mandate, scope and context;
• independent, immutable logging that the agent itself cannot edit.

The NIST workshop material on incident management discusses coordinated responsibilities, evidentiary and reporting needs, and operational controls relevant to agent containment and credential revocation. In our analysis, these findings support determining in advance who can stop an agent, revoke credentials and, where applicable, approve resumption.

Which three roles does dual authorisation separate in an enterprise workflow?

Our analysis of dual authorisation distinguishes three roles: the AI agent produces an action proposal, a separate policy layer checks that proposal, and at predefined high impact a human approver can release separately. The roles must be set up so that the agent cannot set its own authorisation or approval status.

In our assessment a workable chain looks like this:

1. The agent submits a minimal proposal with source context, purpose, parameters and expected impact — no more than necessary.
2. The policy layer checks whether agent identity, human principal, data classification, tool scope and transaction fall within the signed mandate. This decision is deterministic, not determined by the language model.
3. The human approver gives a separate, action-bound approval for predefined consequential or irreversible actions; the approval mechanism must be designed so that the agent cannot take or alter the decision itself.
4. Execution. Our proposed workflow carries out the action with short-lived credentials and records agent identity, mandate, policy decision, human identity, approval, result and any revocation in independent append-only logging.

The sources are design tenets, concept material and workshop results; collectively, they are not a binding standard and do not prove that a concrete implementation is safe. How exactly risk thresholds are set and enforced without the agent being able to influence them is left open by the texts. In our assessment this is precisely the core that an organisation must place with the policy layer itself, not with the agent. We previously set out the broader control of such tool calls in our analysis on authorisation and containment of agent tool calls.

How do I prevent consent fatigue without letting risky actions through without human release?

By recording risk classes in advance and tying only the highest classes to human release. In the summary of comments NIST names the risk of consent fatigue when people have to give approval for routine tasks too often. Our analysis is that approval can thereby degenerate into a reflexive click and can become less meaningful as a control.

A manageable classification ties human approval to impact, not to frequency:

• reading and preparing — usually policy-based checking only, no human step;
• changing internal data — policy checking, selective human release for sensitive classification;
• sending externally, transferring money or deleting — always fresh, action-bound human approval on a separate channel.

Those who require approval everywhere get token control; those who require it nowhere lack the brake on irreversible actions. We described the same logic on selective oversight in our analysis on measurable human oversight of AI advice.

What do these design tenets mean for directors, lawyers and CISOs?

Our analysis: because NIST's tenets point strongly towards separated authorisation, a CISO must map where agents today run with fixed, broad rights and replace those with decreasing, purpose-bound scopes. Because the agent must not have permanent authority and must not set its own approval status, a lawyer should record in the supplier or procurement contract that agent identity, policy decision and human approval are demonstrably separated and independently auditable. Because NIST ties human escalation to predefined risk thresholds, the board must formally name the risk classes and the competent approvers per type of action, before the first autonomous execution. And because NIST's workshop material discusses coordinated responsibilities during incidents, in our assessment the person who started an action should not be the only one who approves it afterwards, and the agent must not set its own containment status.

In summary, a short agenda follows from this:

• inventory where agents now have permanent, broad rights and replace them with temporary scopes;
• place the authorisation decision with a policy layer outside the language model;
• record risk classes and competent approvers per type of action at board level;
• separate who starts, who stops and who approves resumption during incidents.

These steps fit within a broader approach to agentic AI and AI agents, and connect to our earlier analysis on an incident-response playbook for AI agents.

Sources: The article draws on NIST publications: the design tenets for agent identity, the NCCoE concept paper and summary of comments, the workshop material on incident management, and NIST SP 800-207 on zero trust.