Refunds and returns
Always requires your approvalMoney leaves your account. No agent issues a refund unassisted.
It is not a lock on everything the agent does — that would make catalog browsing pointless. It is a floor that cannot be lowered on what can cause harm: moving money, changing prices, or touching a customer's data.
Enforced in production today — not a roadmap item
Every capability we grant an operator agent carries a minimum threshold assigned by its risk class — not a generic list, one per capability.
Money leaves your account. No agent issues a refund unassisted.
GDPR-class actions. A single human approval is mandatory before data leaves or is erased.
A single approval on a catalogue-wide change is worth a pause, not a blanket block.
PCI-adjacent: configuration changes get a pause before taking effect.
Governance-level changes require a second approver by design.
You can configure your store to require more approval than the default threshold. You cannot configure it to require less. A stricter rule overrides the floor; a looser one never applies.
If something goes wrong, revoking an operator agent's credentials is immediate: we sign a revocation list (the same pattern as a CRL/OCSP) that any verifier can check against our public key.
About the agent managing YOUR store: catalog, refunds, pricing, staff. You, the merchant, set the floor — and it cannot be lowered.
About whether a buyer authorized a specific purchase a shopping agent executes on their behalf. It is a separate, opt-in mechanism, and not covered on this page.
Exact per-capability thresholds, the mandate format, and how it relates to FIDO Alliance's AATWG delegated-authority framework.
See the technical detail