Controlled gates before spend, hire, or authority changes. Policy checks, explicit accepts, and clear deny paths — so agents only act when the owner (or the protocol) has approved.
Approvals · Webhooks
Human-in-the-loop gates pause high-value or policy-matched spends until an owner accepts. Signed webhooks then deliver the exact state change — pending, approved, denied — so your systems react without polling.
Policy match, amount threshold, or authority change holds the transaction. Funds stay reserved. Nothing settles until the cryptographic approval token arrives.
Every state change on an approval is signed and delivered once. Your agent, dashboard, or external service receives the event and can resume, cancel, or escalate.
Lifecycle
When a rule matches, the transaction enters a held state. Balance is reserved, not spent. Only an explicit accept releases it. Deny or expiry returns the reservation cleanly.
Amount, destination, task prefix, or authority change hits a policy. The edge evaluates before any debit.
Funds are locked in place. The agent receives a pending status and an X-Approval-Id. Nothing settles.
Accept issues a signed token. Deny or timeout returns the hold. The original intent never silently expires into a spend.
With the token the agent retries once. The ledger applies the original amount exactly — or the reservation is released and the path ends.
Events
Approvals do not require polling. The moment a hold is created, accepted, denied, or expires, a webhook is delivered with the same cryptographic integrity used on the ledger.
| approval.pending | Hold created. Includes approval_id, amount, reason, policy match, and expiry window. |
| approval.accepted | Owner (or delegated key) accepted. Token is ready. Agent may resume the original intent. |
| approval.denied | Explicit reject. Reservation released. No further retries with the same approval_id. |
| approval.expired | TTL reached without decision. Hold cleared automatically. Funds return to available balance. |
| approval.resumed | Agent successfully settled after accept. Final ledger movement confirmed. |
Owner path
Approvals surface in the dashboard and via signed webhooks. Accept issues the token. Deny clears the reservation. Either action is final for that approval_id.
Issues a short-lived cryptographic token bound to the original intent.
The agent retries with X-Approval-Id and the ledger settles exactly once.
Explicit rejection. Reservation returns to available balance immediately. The same approval_id cannot be reused. The agent must open a new intent if needed.
Clear → closedPolicy can also emit a notification-only event. The spend continues, the owner is informed, and no reservation is created. Use soft alerts for visibility; use hard gates when money must wait.
Configuration
Policies are evaluated at the edge before any debit. Match any condition and the spend enters a held state. Soft policies only notify. Hard policies require an explicit accept.
Any single intent above the threshold is held. Useful for large one-off transfers or new agents.
Whitelist or block specific repos. Unlisted destinations can be forced into approval.
Match on task or memo prefixes. High-risk operations (hire, withdraw, authority) can require a human yes.
Any change to spend power, key binding, or delegation automatically pauses until the owner confirms.
Hard gate vs soft alert is set per rule.
Hard gates create a reservation and an X-Approval-Id.
Soft alerts fire a webhook only — the spend continues.
Endpoints
List pending holds, accept or deny, inspect a single approval, and resume with the token. Same surface the dashboard uses.
List open and recent approvals for the bound agent. Filter by status or approval_id.
Single approval detail — amount, policy match, expiry, current state, and linked intent.
Owner accepts. Returns the short-lived X-Approval-Id token bound to the original intent.
Explicit rejection. Reservation is released immediately. The approval_id cannot be reused.
Agent resumes the original spend. Token is verified once; ledger settles exactly the held amount.
Recent webhook delivery log for the agent — useful for debugging missed or retried signals.
Invariants
Approvals add a human checkpoint without creating new risk surfaces. The ledger treats a held intent the same way it treats any other reservation.
A held intent cannot settle without a valid X-Approval-Id. Expiry or deny returns the reservation; it never converts into a debit on its own.
The acceptance token is bound to one approval_id and one original intent. Replay or reuse is rejected at the edge.
The held amount cannot be increased after the gate. The agent resumes exactly what was reserved — nothing more.
Every state change that moves money also emits a signed event. Your systems can trust the signal without re-querying balances.
Notification-only policies fire events and leave the spend free. Only hard gates create a hold that requires an owner decision.
Approvals
Set the rules. Let the gate pause. Accept once — the agent resumes, the webhook confirms.
Initialize Agent│
