iProov HAPS Binds Human Approval to AI Agent Actions

Key takeaways

Approval is bound to one proposed action.
The draft is experimental and open for review.
Organisations choose which high-risk actions require a person.

iProov HAPS turns a vague “human in the loop” promise into evidence that can be checked before an AI agent performs a sensitive action. Released on September 17 as an experimental, Apache-2.0 specification, the Human Approval and Presence Specification binds a person’s approval to the exact action an agent proposes. It is an early design for scrutiny, not a finished industry standard.

iProov HAPS separates permission from approval

An agent may have valid credentials and still do something its user did not intend. Prompt injection, overly aggressive goal pursuit or misuse of delegated access can all produce actions that remain technically “within permission.” HAPS addresses that gap by asking a relying system to verify fresh, action-specific human approval before it lets a high-risk operation proceed.

The proposed flow pauses the agent, presents the planned action to a person, collects proof of human presence and approval, and returns a signed consent credential. That credential is tied to the action and its presentation, rather than serving as a reusable yes. The draft also includes audience controls, a challenge, an expiry and a single-use identifier, according to iProov and an independent technical report by ID Tech.

Fact	Verified detail
Release	September 17, 2026
Status	Experimental open specification
Licence	Apache-2.0
Implementation	Partial Rust reference code and test vectors
Core control	Signed consent bound to one proposed action

What changes for enterprise agent controls

The useful distinction is between identity, authority and intent. Identity proves who is involved. An access policy says what an agent may do. HAPS is meant to prove that a present human approved this particular request. That could matter for payments, account recovery, record deletion or other actions where a general token should not be enough.

iProov says organisations decide which operations require the extra step, so the model does not demand approval for every agent task. That is important because blanket prompts create approval fatigue. The design is also proof-agnostic: iProov demonstrates biometric liveness, but the specification does not require one vendor or one biometric method.

The release arrives as companies add separate runtime controls around agents. Lapaas Voice has covered both reported model-misalignment incidents and Arcjet’s agent runtime security. HAPS targets another layer: proof of user intent at the moment of a consequential action.

Adoption is the next test

The specification includes schemas, test vectors, a formal model and partial reference code, but those artefacts do not establish interoperability or production readiness. The practical test is whether independent implementers can reproduce the flow, whether security reviewers find replay or presentation weaknesses, and whether relying services accept the credentials without locking customers into one identity provider. Buyers should also test recovery paths, revocation, clock drift and the user experience when proof fails. Audit teams will need logs that connect the approval credential, policy decision and executed action without exposing unnecessary biometric or personal data.