A procedural specification for requiring a human to approve a specific AI agent action before it executes. It defines how approval should be linked to the exact request and verified at the moment of use, so organisations can distinguish between general agent permission and genuine human intent.
What Human Approval And Presence Specification Actually Does
Human approval and presence specification turns a vague “get approval” requirement into a verifiable control. It defines which action needs approval, which human is tied to that request, and what evidence proves the approval existed at the moment the action was allowed to run.
That distinction matters because an AI system can have broad operating permission without a real-time human decision attached to each sensitive action. The specification is therefore about authorization design, not just workflow convenience.
How It Separates Consent, Context, and Execution
The key idea is linkage. The approval must match the exact request that is about to execute, rather than a previous, generic, or loosely related consent event. That means the system has to preserve request context, bind the approver to that context, and verify the approval again at execution time.
This is what makes the term stronger than a simple human-in-the-loop checkpoint. A human may be “present” in the process, but presence is only meaningful if the approval cannot be reused, drift out of context, or be replayed against a different action.
For agentic systems, that also means the approval boundary sits beside the agent’s operational authority. The agent may propose or prepare an action, but the human approval determines whether that specific execution can proceed.
Why This Specification Matters for Agent Actions
Human approval and presence specification is most useful when a request can have real-world side effects, access consequences, or irreversible changes. In those cases, the approval mechanism becomes part of the control plane for the agent, not a cosmetic confirmation step.
It also helps organisations distinguish between standing permission and momentary intent. A general right to use a tool, API, or workflow does not mean a human endorsed every invocation, especially when the request content can change between drafting and execution.
That is why this term often sits near agentic governance, delegated authority, and sensitive action approval. The practical question is whether the system can prove that a human approved this exact action, at this exact moment, under this exact context.
Common Failure Modes and Control Gaps
Approval controls fail when they are too loose, too early, or too reusable. Common weak points include approving a category of action instead of a specific action, allowing a stale approval to be replayed, or failing to show what the human actually saw before approving.
Another control gap appears when the approval record does not capture the final parameters that were executed. If the agent can alter the request after approval, then the control no longer proves human intent, only that some earlier version was reviewed.
Presence checks can also be misleading if they only confirm that a person is logged in or nearby. The useful control question is not whether a human exists in the process, but whether the execution decision is bound to a current and attributable human choice.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Covers agent authority and approval boundaries for sensitive actions. |
| Recommendation — Bind human approvals to the exact agent action before execution. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Defines enforcement of approved access and action conditions for controlled operations. |
| IA-5 — Authenticator Management | Supports verifiable human presence and approval attribution through controlled authenticators. | |
| AU-10 — Non-repudiation | Supports proof that a specific human approved a specific action at execution time. | |
| Recommendation — Enforce execution only when the recorded approval matches the requested action. Use strong authenticators to attribute approval to the correct human at use time. Log approval evidence so the executed action can be tied to the approving human. | ||
| OWASP ASVS | V8 — Authorization | Authorization requirements help ensure the executed action matches the approved intent. |
| Recommendation — Require authorization checks that validate the exact requested action before execution. | ||
Practitioner Guidance
Why practitioners should care: Treat this as a control design problem, not a UI prompt problem. The approval must be linked to the exact action payload, because broad “approve once” patterns create false confidence and leave room for drift between review and execution.
Common misunderstanding: Teams often assume that any manual checkpoint satisfies human approval. In practice, the checkpoint only counts if it is specific, current, and resistant to replay or parameter changes.
Practitioner takeaway: If you cannot prove what the human approved, when they approved it, and what was actually executed, the specification has not been met.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
