When Your AI Works Without You, Who Decides What It Can Do?

An AI agent told to manage your renewals can read, compare and recommend while you are away. Can it also sign? Delegated authority, approvals and revocation for unattended agents.

Concept illustration for AI agent permissions: an agent branches to two actions across a policy line, a document marked Allowed and an email marked Needs approval.

Imagine assigning an AI agent to manage your company's software renewals while you are away.

It can review upcoming contracts, compare supplier prices, prepare recommendations and alert the procurement team when a decision is required.

Now suppose a supplier offers a substantial discount, provided the company accepts a longer contract and commits to payment before the end of the day.

The agent recognizes the opportunity. It has been instructed to manage renewals, and accepting the offer might save money.

But does that instruction give it the authority to commit the company to a new contractual obligation?

This distinction is becoming increasingly important as AI agents move beyond responding to individual requests and begin carrying out responsibilities between conversations.

In October 2026, the US National Institute of Standards and Technology (NIST) published Design Tenets for Agent Identity Management Systems, proposing ten principles for managing agent identity, authentication and authorization.

The guidance examines how agents can operate under delegated authority, how permissions should be constrained and why authorization must remain enforceable as circumstances change.

These are proposed design principles, not new binding legal obligations or an AI certification scheme. Nevertheless, they address a challenge that organizations deploying autonomous workflows must confront:

When an AI agent continues working without direct supervision, how can an organization ensure that its actions remain within the authority originally granted?

A Standing Instruction Is Not Unlimited Authority

Persistent AI agents can be assigned ongoing responsibilities rather than isolated tasks.

An agent might monitor customer communications, prepare financial reports or review supplier agreements at regular intervals.

These responsibilities are useful because they reduce the need for repeated instructions. But the ability to understand an objective does not automatically establish permission to perform every action that might help achieve it.

Consider three activities within a software-renewal workflow.

An agent reads a supplier's renewal notice. It then prepares a recommendation comparing available plans. Finally, it attempts to accept revised contract terms on behalf of the company.

Although all three activities contribute towards the same objective, they create different consequences.

Reading a document generally involves access to information. Preparing a recommendation produces material for someone else's consideration. Accepting a contract may create financial and legal obligations.

An instruction to manage renewals should therefore be interpreted within the permissions that the organization has actually established.

NIST's proposed design tenets address this through the concepts of delegation, least privilege and mandates.

Its second tenet concerns linking an agent's activities to the person or organization on whose behalf it operates. It also proposes that authority delegated to downstream agents or services should never exceed the authority of the delegating entity.

Its third tenet emphasizes least privilege and zero standing privilege, limiting access to what a designated task requires rather than maintaining broad permissions while an agent is idle.

Least privilege is not new to AI agents. NIST SP 800-53 Revision 5, the US catalogue of security and privacy controls, treats it as an established access-control requirement for information systems. The design tenets apply that requirement to agents whose tasks start and end without a person present.

The sixth tenet introduces mandates: statements defining an agent's intended outcomes and constraints, which may be cryptographically signed and used to support authorization decisions.

Together, these principles provide a foundation for distinguishing the work an agent has been asked to perform from the authority it has been granted to perform it.

For a business, a practical mandate should identify the responsible owner, permitted resources, allowable actions, spending or operational limits, duration of authority and circumstances requiring escalation.

These elements must be reflected in enforceable controls rather than depending entirely on the agent's interpretation of its instructions.

What Happens When an Agent Encounters a Decision It Cannot Make?

Return to the procurement example.

The agent has been authorized to examine renewal options and prepare recommendations. A supplier then introduces a time-limited discount that would extend the contract by another year and change the billing entity.

Accepting the offer may appear commercially attractive. But urgency does not create additional authority.

The agent can continue gathering information, comparing the revised terms and preparing a recommendation. The decision to accept the new commitment should be referred to someone with the appropriate authority.

This is where human approval becomes an important part of unattended AI workflows.

A meaningful approval request should provide enough information for the reviewer to understand the proposed action and its consequences.

In the procurement example, that information would include the supplier, proposed contract duration, total financial commitment, changed billing details and deadline for acceptance.

The person approving the transaction should also understand exactly which action their approval authorizes.

Approval of one renewal proposal should not automatically authorize a materially different transaction. If the supplier changes the amount, recipient or contractual terms after approval, the revised action may need to be assessed again.

NIST's fifth design tenet addresses human-in-the-loop triggers, proposing that organizations establish risk thresholds that initiate review by an appropriate authority.

The guidance also recognizes what NIST calls consent fatigue. Excessive requests can encourage people to approve actions habitually without considering their implications.

The objective is therefore to establish sensible boundaries between routine work and consequential decisions.

Not every step requires human intervention. Organizations should identify the actions an agent may perform under standing permission and those that warrant a fresh decision.

Can Repeated Approvals Become Standing Permissions?

A recurring workflow creates a practical question: if someone repeatedly approves the same type of action, should the agent eventually be permitted to perform it without asking again?

There may be situations where reusable permissions improve efficiency.

For example, an organization might authorize an agent to generate a weekly internal report from designated sources without requesting approval each time.

But repeated approval should not automatically expand the agent's authority.

An employee who has approved several supplier payments has not necessarily authorized every future payment to that supplier, regardless of amount or circumstances.

Anthropic's October 2026 publication, Claude Duet Safety, Privacy, and Security, offers an example of how a commercial AI developer is addressing this distinction.

Anthropic explains that Claude Duet uses approval mechanisms and separate automated checks to assess certain actions before execution.

Its documentation distinguishes actions that may be performed under reusable permissions from actions that continue to require confirmation, including specified payment, order-deletion and account-creation activities.

Anthropic also identifies some actions that remain prohibited even when a user attempts to approve them.

These are product-specific safeguards described for a research-preview system, not independently verified guarantees about every possible outcome.

They nevertheless illustrate a broader governance principle: the frequency with which an action has been approved is not, by itself, a sufficient reason to expand delegated authority.

Organizations need explicit rules determining when permissions can be reused, who may grant them and which categories of action must return to an authorized decision-maker.

Why AI Agent Permissions Must Remain Revocable

Delegating authority is only part of the problem. Organizations must also be able to withdraw it.

Consider an AI procurement agent that has been authorized to prepare a renewal and is waiting for the next execution window.

While the agent is inactive, the procurement manager discovers that the supplier is no longer approved. The manager withdraws the agent's authority to proceed.

What happens when the agent resumes?

If it relies only on permission granted when the task was originally created, it may continue with an action the organization no longer authorizes.

This is why authorization needs to be evaluated against the circumstances that exist when an action is attempted.

NIST's fourth design tenet proposes short-lived, dynamic and revocable authorization, including runtime verification of individual tool calls, API requests and resource access.

In practical terms, withdrawing permission should affect future actions that depend on it.

However, organizations must distinguish three different situations.

Stopping an agent from initiating new work is one control. Preventing an already queued action from executing is another. Addressing a transaction that has already been completed requires a separate process.

Revoking authority does not automatically reverse a payment, cancel a signed agreement or recall information already sent to another party.

A well-designed workflow should therefore make permission withdrawal effective before the next consequential action and preserve sufficient records to establish what happened before and after the change.

For the procurement assistant, a useful test would be to withdraw purchasing authority after a renewal has been prepared but before it is executed.

The organization could then verify whether the pending action is refused, whether the task reflects the changed authorization and whether the attempted execution is recorded accurately.

This produces evidence about the specific revocation control being tested rather than relying on a general assurance that the agent can be stopped.

There is a further distinction that businesses should consider when allowing AI agents to interact with suppliers, customers or financial institutions.

An organization's internal permission system determines what its technology is allowed to do. Whether a particular action creates legally enforceable obligations is a separate question.

Under common-law agency principles, for example, the authority of a person acting on behalf of an organization may involve express, implied or apparent authority. The circumstances in which a counterparty can rely on that authority depend on the applicable law and facts.

The Cornell Legal Information Institute's explanation of agency law illustrates these distinctions in a US legal context.

AI software should not automatically be treated as a legal agent merely because it is called an AI agent. Nevertheless, transactions initiated through automated systems can create contractual questions concerning the organization operating the system, the authority of the people configuring it and the representations made to counterparties.

A procurement platform's approval rule may prevent an unauthorized transaction from being executed. But an internal access-control setting does not, by itself, determine whether an external contract would be enforceable if an unauthorized transaction nevertheless occurred.

That outcome depends on the relevant jurisdiction, contractual arrangements and circumstances.

This gives organizations an additional reason to define the limits of automated commitments clearly and ensure that technical permissions correspond with their internal governance and legal authorization procedures.

AI Agent Governance Requires Controls Outside the Model

An agent may be able to interpret a user's intention and propose an appropriate next step. That does not mean it should independently determine whether it has permission to execute the step.

This distinction is central to NIST's seventh and eighth design tenets.

The seventh proposes separating the systems responsible for determining permissible actions from the reasoning components that decide what an agent attempts to do.

The eighth emphasizes deterministic access decisions as the primary basis for authorization. AI-generated assessments may inform a decision, but probabilistic reasoning should not become the sole authority for access to sensitive resources.

For example, an AI model might determine that accepting a revised supplier contract would be beneficial.

A separate authorization mechanism should determine whether the requested operation falls within the agent's permissions, whether applicable limits have been exceeded and whether an authorized person must approve it.

The model's confidence in the commercial benefit does not change those permission boundaries.

NIST's tenth tenet also addresses evidence of agent identity, delegated intent and resulting actions through independent, tamper-evident records.

Such evidence can help organizations reconstruct the sequence of authorization and execution decisions.

However, a signed record establishes only what the underlying mechanism reliably recorded. It does not automatically prove that a transaction was commercially appropriate, legally valid or correctly interpreted.

These distinctions are important when assessing whether governance mechanisms operate as intended.

For a related discussion of the limits of automated evidence checking and human judgment, see our earlier article, When AI Checks AI: Where Does Human Oversight Begin?.

How ZeroH Approaches Governed Agent Actions

At Blade Labs, these questions inform the development of ZeroH's runtime governance capabilities.

ZeroH Guard is the component that enforces what Zero, Blade Labs' personal AI agent, is allowed to do. It includes mechanisms for policy evaluation, approval handling and signed decision records. The ZeroH enterprise platform applies the same pattern through policies enforced before a model is called, approval gates and a signed ledger of agent actions, so that an organization's permission rules become decisions about proposed agent actions.

The architectural distinction is important.

An AI model may propose an action based on its understanding of a task. A separate governance mechanism evaluates whether that action is permitted within the configured controls.

This creates a foundation for controlling agent behavior without relying exclusively on the model's own assessment of what it should be allowed to do.

The implementation of individual mechanisms should nevertheless be distinguished from evidence that every action is covered or that an entire customer workflow has passed end-to-end acceptance testing.

Blade Labs' roadmap also includes the ZeroH Classifier, a planned capability that would check each step an agent takes for risk and learn from permission decisions to inform future assessments of agent actions. Blade Labs lists it as coming soon, first for third-party coding agents and then for Zero, and states that it can never widen a user's rules on its own.

The proposed direction raises an important governance consideration: learning from previous approvals must not become an uncontrolled mechanism for expanding authority.

Any such capability would need defined boundaries for which decisions it may inform, how organizational rules take precedence and when human authorization remains necessary.

The Classifier should therefore be understood as a development direction rather than an already available or fully tested feature.

Ultimately, the effectiveness of runtime governance depends on whether permission boundaries remain enforceable throughout the execution of a task, including when instructions, access rights or circumstances change.

Conclusion: Delegated Authority Must Have a Defined Boundary

As AI agents take on longer-running responsibilities, organizations will increasingly need to distinguish between assigning work and authorizing actions.

A standing instruction can define what an agent should accomplish. It should not silently become unlimited permission to access systems, disclose information or create commitments.

Meaningful delegation requires clear boundaries around what an agent may do, how long its authority remains valid, which decisions require approval and what happens when permission is withdrawn.

For organizations deploying unattended AI workflows, a practical starting point is a single recurring assignment.

Define the permitted actions, identify the decisions carrying greater consequences and test whether the system responds correctly when authority changes while work is pending.

The result should establish more than whether an agent completed a task. It should demonstrate whether the actions taken remained within the authority actually granted.

At Blade Labs, ZeroH's policy and approval mechanisms are being developed around this challenge: enabling AI agents to act within defined governance boundaries while preserving human accountability.

Explore how ZeroH approaches governed AI agent execution.

Blade Labs is taking on design partners: 90 days with your team, your jobs set up, first landing in week one. Become a design partner.


Frequently Asked Questions

1. What are AI agent permissions?

AI agent permissions define the resources and operations an agent is authorized to access or perform. Depending on the system, permissions may specify particular tools, data, actions, time limits and approval requirements. Effective permission management also considers the circumstances in which access should be restricted or withdrawn.

2. Does a standing instruction give an AI agent authority to complete every necessary action?

No. A standing instruction describes the work an agent is expected to perform, but the actions it may take depend on the authority granted through the organization's policies and technical controls. For example, an agent authorized to prepare a procurement recommendation should not automatically be permitted to accept a contract or initiate a payment.

3. How should organizations manage human approval for autonomous AI agents?

Organizations should identify which actions fall within existing permissions and which require fresh authorization. Approval requests should disclose the proposed action, relevant context and consequences. NIST's proposed design tenets recommend risk-based human review while acknowledging the need to avoid what NIST calls consent fatigue.

4. What happens when an AI agent's permission is revoked?

Revoking permission should prevent future actions that depend on the withdrawn authority, provided the revocation is enforced at the relevant execution point. It does not automatically reverse transactions already completed. Organizations should separately test new actions, queued operations and recovery procedures to determine how their systems handle permission withdrawal.

5. How does ZeroH Guard relate to the planned ZeroH Classifier?

ZeroH Guard, the enforcement component of Zero, Blade Labs' personal AI agent, includes implemented mechanisms for policy evaluation, approval handling and signed decision records. The ZeroH enterprise platform applies the same pattern through policies, approval gates and a signed ledger of agent actions. The ZeroH Classifier is a planned capability intended to learn from permission decisions and inform future action assessments. Its proposed functionality should not be confused with an already delivered, universally deployed authorization system.


References

  1. National Institute of Standards and Technology (NIST). Design Tenets for Agent Identity Management Systems. Cybersecurity Insights, 27 October 2026.
  2. Anthropic. Claude Duet Safety, Privacy, and Security. 23 October 2026.
  3. National Institute of Standards and Technology (NIST). Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53 Revision 5. September 2020, with subsequent updates.
  4. Cornell Law School, Legal Information Institute. Agency. Wex Legal Encyclopedia, last reviewed October 2024.
  5. ZeroH. Your Sovereign, Governed AI Workforce. Official product website, undated.
  6. Blade Labs. Zero. Product page describing ZeroH Guard and the ZeroH Classifier, undated.