Orchestration & Agentic Security · High-Impact Action Approval and Irreversibility Controls
Bind approvals to the exact action
Verify that approvals are cryptographically bound to action parameters, requester identity, execution context, and a unique single-use nonce, and are rejected if any bound value changes or the nonce is reused.
OWASP AISVS v1.01, requirement 9.2.8
In plain English
Tie each approval cryptographically to the exact action it covers, who asked, the context and a one-time value. An approval then cannot be replayed, moved to another action or used after the parameters change. This is a Level 3 control for high-stakes agent actions.
What good looks like
- Each approval is a signature over the canonical action parameters, the requester's identity, the execution context (such as run and session ID) and a unique nonce.
- The gateway recomputes the binding before running the action and refuses if anything differs.
- A nonce works once. Reuse is rejected.
- Approvals expire after a short time.
How teams usually do it
- A signed approval token (for example a JWT or similar signed object) containing a hash of the canonical action, the context identifiers, a nonce and an expiry.
- Verification in the tool gateway, backed by a store of used nonces.
- A defined canonical form for parameters, such as the JSON Canonicalization Scheme (RFC 8785), so the same action always hashes the same way.
Suggested evidence
- The approval token format.
- Tests showing an approval fails when a parameter changes, when it is replayed, and when used in another session.
Common mistakes
- An approval that says "yes" without saying to what.
- Hashing a display string in place of the real parameters.
- Approvals with no expiry.
Not sure which requirements apply to your system? Take the assessment, or browse every guide in this chapter.
Requirement text from the OWASP AI Security Verification Standard, licensed under CC BY-SA 4.0. This guidance is shared under the same licence.