Define a threshold policy (e.g., any single purchase > $50, or any merchant category outside a pre-approved list) stored in configuration, not hardcoded in agent logic.
When the agent assembles a purchase intent exceeding the threshold, publish an approval request event to a queue (e.g., SQS, pub/sub) with full purchase context: merchant, amount, reason, agent session ID, and a short-lived approval token.
Deliver the approval request to a human via a durable channel (email with a signed approve/reject link, Slack with interactive buttons, or a dashboard with pending approvals); set a TTL of 10–30 minutes.
The agent enters a wait state, polling or subscribing to the approval response topic — it must not proceed or time out silently; on TTL expiry without a response, treat as rejected and surface the failure to the user.
On human approval, the approval service issues a one-time payment authorization token to the agent and records the approver identity, timestamp, and approval context in the audit log.
The agent uses the approval token within its validity window to execute the payment; the token is single-use and bound to the specific merchant and amount approved.
Known gotchas
Approval links must be signed and time-limited — an unsigned 'approve?id=123' endpoint is a trivial CSRF target; use HMAC-signed URLs or OAuth-style one-time codes.
Agents can accumulate pending approvals across parallel tasks; build a de-duplication check so the same logical purchase doesn't generate multiple approval requests if the agent retries.
If the human approves but the agent has already timed out and abandoned the task, the issued token must still be invalidated — orphaned approval tokens are a spend-control gap.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp