After the agent demo, the permission screen becomes the product

MoonPay's PayBox documentation describes separate agent clients with grants governing credentials, operations and approval rules. Revocation stops further requests. It distinguishes wallet and card outputs from named secrets, which can be returned directly when a grant permits it. These are documented product claims, not an independent security audit.

For teams coming out of a hackathon, the next useful demo may be a refusal. Ask the assistant to buy from the wrong merchant, exceed the intended budget, or reuse a canceled instruction. A convincing product should explain the boundary to the user and give the operator enough information to understand what happened. A successful purchase alone cannot show that.

Consent also needs to remain understandable after the first setup. Our product test would ask someone to describe, without help, what the assistant is allowed to do tomorrow. If the answer is simply that it has access to everything, the permission design deserves another pass. Separating routine purchases from exceptional approvals can make that conversation more concrete.

For a small business, the operational question is who can stop an agent when its usual operator is unavailable. Assign that responsibility, rehearse it with harmless test requests, and inspect the resulting record. This turns an impressive conversational interface into a workflow that a real team can supervise.