Ship AI actions users can revoke: spend, send, delete, book

If your AI can spend, send, delete, or book, the user needs a revoke path before launch. A model that books a table, pays for groceries, or deletes a file has crossed from assistant to actor. The interface must show the boundary before the action happens.

Trust in these features is built in the control surface, not the model card. Users do not need to understand the prompt. They need to know what the agent may do, what it may not do, and how to stop it. Treat every irreversible action like an authorized cardholder: approval by default, capped autonomy, task-scoped data, a separate revocable agent identity, and a human backstop.

Walmart is making agent authority visible

The Walmart Agent Gateway launched to manage transactions and other features for customers using AI agents. Next month, Agent Profiles will give each AI agent its own account profile so customers can distinguish agent purchases from their own. Customers can approve each agent purchase individually or set a spending ceiling, with $50, $100, and $200 cited as example ceilings, and can remove an agent profile whenever they want.

The default control will require approval for every AI agent purchase, although customers can permit an agent to shop within a budget such as up to $100. The agent rules keep an agent within the shopper's intended actions, forbid changing the customer's payment method, limit data access to what the task requires, and block agents that break the rules.

The Agent Gateway is intended to help agents locate a customer's regular items, such as a usual bread or milk brand, without exposing the customer's broader purchase history to the agent. The returns process applies when an agent fails to act as intended. That path belongs in the control surface, not in support.

The six-line audit is the redesign

Give the agent a bounded task. The six lines below are the minimum surface for any AI feature that can spend, send, delete, or book. Each line closes a different way an agent can surprise a user: money, scope, data, payment, identity, and recovery.

• Approval is the default, and autonomy is capped. Irreversible actions wait for consent unless a user-set limit is active.
• Intent is bounded. The named task is visible, and out-of-scope actions are blocked.
• Data is task-scoped. Only the records the task requires are readable.
• Payment access is denied. No payment method can be added, changed, or selected beyond the approved one.
• Identity is revocable. A separate profile exists, and the user can pause or delete it.
• A human backstop exists. A person can review, stop, or reverse the action, with a visible failure path.

If one line is missing, the user is left to infer the boundary from a transcript. That gap is a launch risk, and it should be visible in the UI.

The common failure is the confident summary: table booked. The user sees a result, not the authority that produced it. The redesign is a two-part surface. First, show the action in the user's words: book, send, delete, pay. Second, show the permission that allowed it: approved, within limit, or blocked. The surface should name both in the same screen, before launch.

Make the backstop a control, not a promise

A human backstop must be a visible control: pause, review, reverse, or escalate. For spend, send, delete, and book actions, it should be part of the control surface, not a post-complaint fix. The agent can be fast, but the user must always have a stronger control.

For bookings, the backstop is a change or cancel control. Sends need a draft state or a recall window. Deletes need a trash state with a visible restore action. Spending needs a receipt, a cap, and a way to dispute the charge.

Check the revoke path: can the user pause, reverse, or stop the action without a ticket, a lawyer, or a guess?