Approval gate

Part of the Learn hub and the customer data glossary.

What it means in practice

An approval gate rests on three rules. The approver is never the requester. Approval binds to a hash of the exact payload, so a later change voids it. Timeouts expire; they never auto-approve.

The gate belongs in an approval service outside the agent, so a model cannot grant itself a pass. Workflow tools supply the waiting. A Temporal recipe uses a Signal and a timer, and only an explicit approval lets the action run 1. LangGraph's interrupt pauses a run until the caller responds, with a durable checkpointer recommended for production 2. The rail adds who may approve and exactly what they approved.

The Model Context Protocol specification says there should always be a person able to deny tool invocations 3. Check how your vendor's agents behave.

A gate only works if people read what they approve. EU AI Act Article 14(4)(b) names automation bias for high-risk systems 4, and a marketing queue is open to the same habit. Show the diff and counts, and watch the override rate: near zero may mean rubber-stamping.

PrivyCDP's immutable audit ledger records each AI-assisted action with the human or system actor that authorised it, which gives a gate's decisions a lasting record.

Example (credit union, illustrative): the Audience Sync Steward, at L3, presents a sync plan with destination and count. A named approver signs it. Someone then edits the segment, the hash changes, the approval is void, and the execution service refuses the sync.

Related terms

• Draft-approve-execute split: the pattern around the gate.
• Rail card: the Gate field records it.
• Kill switch: stops what has been approved.
• Audit ledger: records each decision.

Where it matters

• The agent rail card: what the Gate field must say.
• Failed sync retry: when a retry needs no new approval.

Back to the customer data glossary or the Learn hub.