Approving AI-agent actions
What this is
Software agents increasingly act on a person's behalf: they book, pay, send, change settings. For the risky part of that work someone has to say yes — and the confirmation is worth little if it is collected on the same screen the agent already drives. Veriqa moves that step onto a separate surface: the person confirms in their own messenger, in a dialogue the agent is not a party to.
The mechanics are the ones Veriqa already runs for sign-in confirmations: a transaction with an explicit purpose, a message in the trusted channel describing exactly what is being approved, an answer from the person, and an audit record of who approved what and when.
What it is for
- Human-in-the-loop for consequential steps — a payment, an outbound message, a destructive operation — without building a separate approval application.
- A separation between the requester and the approver. The agent asks; the person answers elsewhere. Whoever controls the agent's screen does not thereby control the answer.
- An audit trail of approvals. Every confirmation leaves a record — which action, which channel, which identity, at what time.
Where the boundary runs
This direction inherits the boundary of the rest of Veriqa: the approval rests on the person's trusted channel and on the channel platform's API. It is a strong, convenient step for scenarios where that trust is appropriate — it is not a cryptographic proof of intent, and it does not turn a messenger into a hardware security module. Where the risk model demands more than that, more than this is needed.
Where this stands
Confirming an action already exists in Veriqa: the application creates a confirmation transaction
with the server-to-server request POST /api/transaction/confirmation, receives the channel's deep
link and a QR code for the person, and reads the outcome with GET /api/transaction/{id}/result.
The agent-facing shape on top of it is not there yet — a vocabulary for describing actions, an
integration surface for agent platforms and approval policies.
We are working on this: what works out will appear in releases as it is developed; if the direction does not hold up, this page will say so.