An AI Agent Completed the Task. Can You Prove It Was Authorized?

Consider a hypothetical scenario: an AI agent emails a revised commercial proposal to a customer. The message arrives, the attachment opens, and the task is marked complete.

Later, a manager asks whether the agent was authorized to offer those terms to that particular recipient.

A delivery confirmation cannot answer that question. It proves that an action occurred, not that the action fell within the authority granted to the agent.

As AI agents take on responsibilities across business applications, organizations need to establish more than whether work was completed. They must also be able to demonstrate what authority governed an action when it was executed, whether the action remained within that authority, and what evidence supports that conclusion.

This is the distinction between recording an outcome and establishing runtime accountability.

Why AI agent authorization requires more than an activity log

In September 2026, the US National Institute of Standards and Technology (NIST) published a summary of stakeholder comments on software and AI agent identity and authorization. Among the concerns identified was that conventional audit logs can show what happened without adequately capturing the authority, context or decisions behind an action.

The observations are informing NIST’s continuing work on agent identity and authorization. They are not requirements under a completed technical standard.

NIST advanced this discussion on 27 October 2026 with its Design Tenets for Agent Identity Management Systems.

The proposed tenets address several challenges directly relevant to autonomous agents: establishing distinct identities, constraining delegated authority, separating policy enforcement from agent reasoning, and maintaining independent records of agent activity.

One tenet explores cryptographically signed mandates that define intended outcomes and constraints. Another emphasizes that decisions about what an agent is permitted to do should remain separate from the system determining what the agent wants to do.

Together, these principles point toward an important distinction: an agent’s ability to perform an action is not evidence that it was authorized to perform it.

Record authority at the moment of action

Organizations already distinguish authentication from authorization. Authentication establishes who or what is making a request; authorization determines what that identity is permitted to do.

For AI agents, the additional challenge is preserving the scope of delegated authority as work progresses through different tools and systems.

NIST SP 800-207, Zero Trust Architecture, provides a useful architectural foundation. It separates the policy engine that makes and records access decisions from the mechanisms that administer and enforce them.

Applied to agent workflows, this suggests that permission should be checked at the relevant action boundary, with evidence retained of the decision that governed it.

A general instruction to assist a sales team, for example, should not automatically authorize an agent to send any commercial proposal it produces. Permission may depend on the customer, proposed terms, recipient, approval status and time of execution.

The organization therefore needs evidence that connects the specific action to the authority under which it proceeded.

What should an AI agent decision receipt contain?

A decision receipt is a structured record that helps reviewers reconstruct the authority governing a particular action. Its usefulness depends on connecting the relevant evidence, rather than simply collecting additional logs.

For consequential actions, a practical receipt design should answer four questions.

1. Who delegated authority, and what was permitted?

Identify the person or organizational authority responsible for the task, the agent executing it and the relevant scope of delegation. That scope may include permitted operations, resources, limits and expiry conditions.

2. What authorization decision was made?

Record the policy or permission evaluated, its applicable version, the decision and its time. Where human approval is required, retain evidence identifying the approver and the action presented for approval.

3. What action actually occurred?

Connect the authorization decision to evidence from the system executing the action. This may include the receiving system’s transaction identifier, execution status and timestamp. An attempted operation must remain distinguishable from a successfully completed one.

4. Can the records be reliably connected?

Link the delegation, approval, action request and execution result through stable identifiers and relevant content versions. This helps establish whether the action ultimately performed was the action originally authorized.

The records must also reflect permission changes between approval and execution. An approval that was valid earlier should not remain effective if its scope has expired or the proposed action has materially changed.

Authorization and execution are separate events

Consider the commercial-proposal example again.

A sales director approves a proposal for a named customer, a specified recipient and an agreed discount. Before sending it, the agent modifies the attachment.

The approval still exists, but it now relates to an earlier version of the proposal.

The correct response depends on the organization’s authorization policy. If the change affects the approved terms or otherwise exceeds the permission granted, the action should be re-evaluated and, where necessary, returned for approval.

This distinction can be tested.

Change the recipient or attachment after approval. Attempt the action using an expired permission. Then inspect whether the control prevents unauthorized execution and whether the resulting evidence explains what happened.

A reviewer should be able to identify the approved version, the version submitted for execution and the receiving system’s recorded outcome without relying on the agent’s own explanation.

The authorization record establishes what was permitted. Execution evidence establishes what the system actually did. Neither record automatically proves the other.

Where a downstream system does not provide reliable confirmation, the receipt should preserve that evidentiary limitation rather than treating an attempted action as a verified completion.

An industry example: Google’s Agent Payments Protocol

The distinction between delegated authority and specific execution is also emerging in industry protocols.

In September 2025, Google announced the Agent Payments Protocol (AP2), an open framework designed to support payments initiated through AI agents.

For a purchase made while the user is present, Google’s design uses a Cart Mandate linked to the user’s approval, recording the specific items and price.

For delegated purchases where the user is absent, an Intent Mandate can establish conditions in advance, including price limits and timing.

The two situations involve different approval arrangements, but both require a way to connect the transaction to the authority supporting it.

AP2 concerns agent-led payments; it is not a general authorization standard for all business workflows. Nevertheless, the underlying principle is relevant to other consequential actions: permission should be tied to defined conditions and evaluated against what is actually being executed.

What decision receipts cannot prove

Even a complete authorization record has limits.

An authorized action may still be commercially unwise. An approver may accept an incorrect amount, or an agent may misunderstand the underlying task. A receipt can establish the decision made and the action taken without establishing that either was substantively correct.

Similarly, tamper-evident storage can help reveal subsequent changes to a record, but it cannot guarantee that the information originally recorded was accurate or complete.

There is also a risk of incomplete system coverage. If an agent acts through a tool or application that does not participate in the evidence process, investigators may be unable to reconstruct the entire workflow.

This is why human oversight remains important. Evidence supports the review of decisions; it does not replace responsibility for those decisions.

Organizations must also consider how much information a receipt needs to contain. Authorization and accountability should not become a justification for unnecessarily retaining sensitive customer data.

NIST’s zero-trust guidance and its recent agent-identity design tenets provide useful technical direction, but they do not, by themselves, establish compliance with applicable legislation or sector-specific regulatory requirements.

Where ZeroH fits

At ZeroH, the approach to governed AI execution is based on separating what an agent proposes to do from the controls that determine what it is allowed to do.

The platform’s architecture combines policy evaluation, controlled tool access, approval decisions and runtime audit records. These mechanisms are intended to make authorization decisions enforceable and their outcomes reviewable.

The supporting audit-service implementation includes structured runtime-decision records, cryptographic signing and records of relevant policy versions, approval outcomes and execution-related decisions.

ZeroH’s Proof & Compliance documentation describes how signed events, approval information and audit records contribute to an evidence trail generated as work is performed.

The important distinction is between preserving evidence of a control decision and demonstrating the complete outcome of an external action. A signed decision receipt can help establish what the runtime permitted, but proving that a receiving system executed the authorized action requires the relevant downstream evidence to be captured and connected.

This provides a practical way to evaluate governed AI systems: select a consequential action and test whether its permission, approval and execution records can be independently reconciled.

As discussed in our earlier article on keeping AI agents within authorized boundaries, enforcement must occur at the point of action, not merely through instructions to the model.

Decision receipts address the complementary question: once an action has been attempted or completed, can an organization reconstruct the authority and evidence behind it?

Conclusion

As AI agents move from generating recommendations to executing business tasks, successful completion is no longer a sufficient measure of trustworthy operation.

Organizations need to establish whether each consequential action remained within its delegated authority and whether the relevant evidence can be independently reviewed.

That requires a clear connection between permission, approval where necessary, the action submitted for execution and the result recorded by the receiving system.

Before expanding an agent’s responsibilities, organizations should test whether they can reconstruct one completed action from authorization to outcome.

That is the difference between knowing an AI agent finished the task and being able to demonstrate that it was authorized to do so.

Explore ZeroH’s approach to governed AI execution and verifiable evidence.

Frequently Asked Questions

1. What is AI agent authorization?

AI agent authorization determines which actions an AI agent is permitted to perform, under whose authority and subject to what restrictions. It may involve delegated permissions, resource limits, policy checks and human approvals. Authentication establishes the agent’s identity; authorization determines the permitted scope of its activity.

2. What is a decision receipt for an AI agent?

A decision receipt is a structured record of an authorization decision associated with an agent’s action. Depending on the implementation, it may identify the agent, delegated authority, policy version, approval outcome and related execution evidence. It helps reviewers assess whether an action remained within the authority granted.

3. How is an approval record different from proof of execution?

An approval record shows what action was authorized. Execution evidence shows what the receiving system attempted or completed. To demonstrate that an authorized action was performed, an organization must connect the approval to the actual operation, including relevant identifiers, parameters and outcomes.

4. Does every AI agent action require human approval?

No. Routine actions may proceed under predefined permissions and enforceable policies. Higher-risk or consequential actions may require human approval, depending on the organization’s rules and applicable obligations. The important requirement is that actions remain within their authorized scope, whether permission was granted in advance or at the point of execution.

5. Do AI agent decision receipts establish regulatory compliance?

Not by themselves. Decision receipts can support auditability, accountability and regulatory evidence requirements, but compliance depends on the applicable legal framework, the organization’s obligations and the effectiveness of its controls. A receipt cannot establish that an underlying business decision was correct or that every relevant legal requirement has been satisfied.

References

1. National Institute of Standards and Technology (NIST). Design Tenets for Agent Identity Management Systems. Harold Booth, Bill Fisher, Ryan Galluzzo and Tom Clancy. 27 October 2026. https://www.nist.gov/blogs/cybersecurity-insights/design-tenets-agent-identity-management-systems
2. NIST National Cybersecurity Center of Excellence (NCCoE). Summary of Comments on the Concept Paper. Released 29 September 2026. https://pages.nist.gov/nccoe-ai-identity/summary-of-comments.html
3. National Institute of Standards and Technology. Zero Trust Architecture. NIST Special Publication 800-207. Scott Rose, Oliver Borchert, Stu Mitchell and Sean Connelly. August 2020. https://doi.org/10.6028/NIST.SP.800-207
4. Google Cloud. Powering AI Commerce with the New Agent Payments Protocol (AP2). Stavan Parikh and Rao Surapaneni. 16 September 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol
5. ZeroH by Blade Labs. Keeping AI Agents Within Authorized Boundaries. 28 October 2026. https://blog.zeroh.io/keeping-ai-agents-within-authorized-boundaries/
6. ZeroH by Blade Labs. When AI Checks AI: Where Does Human Oversight Begin? 20 October 2026. https://blog.zeroh.io/when-ai-checks-ai-where-does-human-oversight-begin/
7. ZeroH by Blade Labs. Proof & Compliance. Product and technical information; publication date not indicated. https://zeroh.io/proof-security