NIST: dual authorisation for AI agents

You must now demonstrate that autonomous AI agents in your organisation cannot set their own authority, that policy decisions are made by a separate layer, and that high-impact actions require approval from a human with their own recorded identity.

An analysis of 9 November 2026 of dual authorisation for AI agents argues that autonomous agents must prepare actions but cannot authorise them, with a separate deterministic policy layer enforcing approval and escalating high-impact decisions to human approvers. The National Institute of Standards and Technology published design tenets on 27 October 2026 establishing that agent identity, policy decision and human release must each be independently verifiable. In our assessment, the practical shift is architectural: separation of duties moves from an extra review step to a structural requirement, and you must now map where agents today run with fixed, broad rights and replace those with decreasing, purpose-bound scopes tied to specific actions.

What does separation of duties mean for agent architecture?

The design tenets establish that an AI agent must have its own cryptographically verifiable identity, distinct from human identities, and that delegated authority should decrease over time. Agents must not receive permanent rights. The core principle is that no single agent can combine conflicting privileges, and no agent can set its own authority, approval status or logging. This means the agent reasons and prepares an action, but a separate component takes the authorisation decision. That component must be logically separated from the agent itself and must enforce policy consistently with zero-trust principles: every request is treated as untrusted until the policy layer approves it.

Which concrete controls must you be able to demonstrate?

1. Record agent identity and scope in advance — document each agent's cryptographic identity, its purpose, the actions it may propose, and the data it may access, with all scopes set to expire or require renewal.
2. Separate the policy layer from the agent — implement a deterministic authorisation component that the agent cannot modify, influence or bypass, which checks every proposed action against recorded policy before execution.
3. Tie human approval to predefined risk classes — formally name the risk categories for agent actions, assign competent approvers per category, and require human release only for high-impact decisions, not routine tasks.
4. Make approval independently auditable — ensure that the identity of the human approver, the timestamp, the action approved and the risk class are recorded separately from the agent's logs and cannot be altered by the agent.
5. Establish who can revoke and contain — designate in advance which roles can stop an agent, revoke its credentials and, where applicable, approve resumption, and ensure the agent cannot set its own containment status.

What risks does the current practice create?

When agents run with fixed, broad rights, they become a single point of failure: if an agent is compromised or behaves unexpectedly, it can execute high-impact actions without independent review. The agent itself becomes both proposer and approver, eliminating the brake on irreversible decisions. Logging controlled by the agent is not trustworthy evidence of what happened. Approval fatigue occurs when humans must authorise routine tasks too often, turning approval into a reflexive click rather than a meaningful control. The absence of separate identities for agents and approvers makes it impossible to audit who authorised what, and creates ambiguity about accountability when something goes wrong.

How should you classify actions to avoid approval fatigue?

Approval must be tied to impact, not frequency. A manageable classification reserves human release for genuinely high-impact decisions: those that are irreversible, that affect many users, that involve material financial commitment, or that cross defined risk thresholds. Routine tasks—those that are reversible, affect single transactions, or fall below the threshold—should pass through the policy layer without human escalation. This approach avoids two extremes: requiring approval everywhere produces token control, whilst requiring it nowhere removes the brake on irreversible actions. The policy layer itself must enforce these classifications, and the agent must not be able to reclassify an action to avoid escalation.

What must your procurement and governance processes now require?

Your legal and procurement teams must record in supplier or procurement contracts that agent identity, policy decision and human approval are demonstrably separated and independently auditable. Your board must formally name the risk classes and the competent approvers per type of action before the first autonomous execution. Your incident response playbook must establish that the person who started an action should not be the only one who approves it afterwards, and that the agent must not set its own containment status. Your CISO must map the current state of agent deployments and identify where agents today run with fixed, broad rights, then replace those with decreasing, purpose-bound scopes.

Tooling can enforce the separation of duties and record the audit trail, but the classification of risk, the choice of approvers and the definition of what constitutes high impact remain your own professional judgement. No system can tell you what your organisation's risk appetite is or who should hold approval authority. Those decisions belong to your governance layer, not to the agent or the policy engine.