When you let an AI agent shop for you, you hand a piece of software your payment method, your accounts and your judgement, and a single malicious web page can try to take over all three. AI assistants, agentic browsers and checkout integrations can now search, compare and buy on a person's behalf, and the payments industry is publishing protocols to make those purchases verifiable. This guide explains how delegated shopping works, what can go wrong, which settings and payment choices keep the damage small, how consumer protections may or may not apply, and how security awareness teams should brief staff and customers. It is for consumers who want practical rules, and for the security, fraud and awareness teams who advise them. For the identity architecture merchants and platforms build behind agentic commerce, see the Agentic Commerce Identity Guide.
Key takeaways
- Assume the agent can be tricked. The AP2 specification itself states that it "assumes that preventing prompt injection attacks is infeasible" and treats every LLM and agent as a potential attacker; your settings should assume the same.
- Limit what the agent can spend. Single-use or capped payment methods, short expiry and per-merchant limits turn a manipulated agent into a bounded loss rather than an open account.
- Keep yourself in the loop for money. Approve each purchase where the tool allows it ("human present"), check the merchant name on every approval screen, and reserve unattended buying for small, repeat, low-risk orders.
- Separate the agent from your main accounts. An agent browsing with your logged-in sessions can reach email, banking and cloud storage if it follows hidden instructions.
- Protections may not fit cleanly. Card liability rules cover unauthorised use, but a purchase your own agent made with your authority may be treated differently; keep records and act quickly.
How AI shopping agents work
Most consumer shopping agents follow the same loop: you state an intent ("running shoes under 100 pounds, size 9, delivered by Friday"), the agent searches and compares, builds a basket with a merchant, and pays using a credential you have shared or a token issued for the purchase.
| Model | What it looks like | What the agent holds | Main risk |
|---|---|---|---|
| Agentic browser or computer-use assistant | The agent drives a browser, often in your logged-in sessions | Your cookies and sessions, sometimes saved cards and passwords | Hidden instructions on pages steer it to act against you |
| In-chat checkout through a protocol | You buy inside an assistant; the merchant receives the order through a protocol such as the Agentic Commerce Protocol (ACP) | A delegated payment token with limits | Wrong item or merchant chosen; over-sharing personal data |
| Mandate-based agent payments | You approve a signed mandate, either the exact basket or a set of constraints, and the agent completes the purchase, as in Agent Payments Protocol (AP2) | Signed mandates bound to a checkout | Loose constraints in unattended mode |
| Browser extensions with shopping features | Extensions that read pages to find deals or fill forms | Broad page access | Malicious or compromised extensions. See the AI Browser Extensions Security Guide |
What the protocols do for you
- ACP delegated payment: the Agentic Commerce Protocol, maintained by OpenAI and Stripe and marked beta, defines a delegated vault token that the merchant's payment provider may use only within an allowance: reason
one_time, amax_amount, a currency, the checkout session, the merchant and anexpires_attime after which the token is invalid. - AP2 mandates: in human present mode you see and approve the final basket and payment; in human not present mode you approve constraints and the agent assembles a purchase within them. Payment credentials are released to the merchant only after a final, verified payment mandate, which binds the token to that transaction.
- Bounded worst case: AP2 notes that even if the model makes a poor choice, constraint enforcement keeps the worst-case financial impact "strictly bounded". The bound is only as tight as the constraints you set.
For the protocol detail see the Agent Payments Protocols Guide.
What can go wrong
| Risk | How it happens | What limits it |
|---|---|---|
| Indirect prompt injection | Text hidden in a product page, review or comment tells the agent to do something else. Brave's August 2025 research on Perplexity's Comet browser showed an assistant acting on hidden page instructions with the user's logged-in privileges, reaching services such as email and banking | Separate agent browsing from your main sessions; confirmation for sensitive actions; capped payment methods |
| Manipulated product choice | Injected content or fake listings push the agent toward a scam shop or overpriced item | Merchant allowlists; price ceilings; review before purchase |
| Wrong or repeated orders | The agent misreads your intent, hallucinates details or retries a checkout | Human present approval; one-time tokens; order notifications |
| Payment credential exposure | Card details stored where the agent or an extension can read them | Tokens or virtual cards instead of real card numbers |
| Account takeover through the agent | The agent is induced to change your delivery address, email or password | Never let shopping agents manage account security settings; MFA with approval on your phone |
| Over-sharing personal data | The agent hands full address, phone, date of birth or preferences to every merchant | Share only what the purchase needs; review permissions |
| Fake agents and apps | Scam "AI shopping assistant" apps or extensions that harvest card details | Install only from the official provider; check reviews and publisher. See the Impersonation Scams Guide |
For the technical background on hidden instructions, see the OWASP LLM Top 10 LLM01 Prompt Injection Guide; the OWASP Top 10 for LLM Applications 2025 also lists Excessive Agency (LLM06) for agents given more power than a task needs.
Setting up an agent safely
- Choose the integration, not the shortcut: prefer in-assistant checkout that uses delegated tokens or mandates over an agent that drives your normal browser with your saved cards.
- Use a separate browser profile or account for agent browsing: do not leave email, banking or work accounts logged in where the agent operates.
- Set up a dedicated payment method: a virtual or single-use card, or a card with a low limit, rather than your main debit card.
- Configure limits: per-order and monthly caps, allowed merchants or categories, and short expiry for any delegated authority.
- Require approval: switch on confirmation for every purchase and for any change to address, email or saved payment details.
- Turn on notifications: real-time card alerts and order emails go to an inbox the agent cannot access.
- Test small: run a low-value order first and check what data was shared with the merchant, which address was used and whether the confirmation reached you directly.
- Know how to switch it off: learn how to revoke the agent's access and cancel the virtual card before you need to.
Choosing how much autonomy to allow
| Mode | Good for | Avoid for | Minimum controls |
|---|---|---|---|
| Research only (no purchase) | Comparing products, finding stock | Nothing; lowest risk | Verify the shop yourself before buying |
| Agent builds basket, you approve (human present) | Most one-off purchases | Purchases you cannot inspect quickly | Check merchant, item, price and delivery address on the approval screen |
| Agent buys within constraints (human not present) | Routine replenishment, price-drop buys, tickets with strict limits | High-value, unfamiliar merchants, gifts to new addresses, travel with non-refundable fares | Tight price cap, named merchants, short expiry, one-time token, alerts |
| Agent with your logged-in browser and saved cards | Rarely justified | Anything involving money or accounts | If used at all: separate profile, no saved cards, confirmation on |
Households and small businesses differ: a family sharing one assistant should give each person their own approval, and a small business letting an agent buy supplies should use a company card with merchant restrictions and a monthly cap, not a director's personal card.
Consumer protections and disputes
In the US, the FTC summarises card liability as follows: for credit cards, no responsibility if you report before the card is used, a maximum of 50 dollars after unauthorised use, and none if only the account number was used; for debit and ATM cards, 0 dollars if reported before use, up to 50 dollars within two business days, up to 500 dollars after two business days but within 60 calendar days of the statement, and potentially everything taken after 60 days. Other countries have their own rules; in the UK see the Authorised Push Payment (APP) Fraud Guide for how authorised and unauthorised payments differ.
- The authorisation question: these rules are framed around unauthorised use. When your own agent made the purchase with authority you granted, a card issuer or merchant may treat it as authorised. How this applies to agent purchases is not settled, so do not rely on chargebacks as the main safety net.
- Keep evidence: the approval screen, the instruction you gave, mandate or receipt records and order emails. AP2 notes that the checkout and payment mandates can be joined in a dispute through a shared hash.
- Act fast: debit card liability rises with time. Revoke the agent, cancel the virtual card and contact the issuer as soon as something looks wrong.
- Fraud follow-up: if card or identity data may have been exposed, consider a credit freeze. See the Credit Freezes and Fraud Alerts Guide.
Responding when an agent purchase goes wrong
- Stop the agent: pause or revoke its access in the assistant's settings and sign it out of any merchant accounts it can use.
- Freeze the payment method: lock or cancel the virtual card or token; most banking apps let you freeze a card instantly, which also stops repeated orders.
- Check what else changed: look at delivery addresses, saved payment methods, email forwarding rules and account recovery details on the merchant and email accounts the agent could reach. A manipulated agent may have changed more than one thing.
- Collect evidence: save your original instruction, the approval screen, order confirmations, receipts and the agent's activity history before anything expires.
- Contact the merchant first: many errors are simplest to fix as a cancellation or return, especially before dispatch.
- Raise a dispute with your card issuer: explain that the purchase was made by an AI agent, what you authorised and what you did not, and supply the evidence. Note the reporting time limits above.
- Report scams: if a fake shop or fake assistant was involved, report it to the platform, the assistant provider and your national fraud reporting service.
- Tighten settings before re-enabling: lower limits, restrict merchants and switch unattended buying off until you understand what happened.
Awareness teams can turn these steps into a one-page card for staff and customers. For organisations, the same sequence belongs in the fraud response process; see the Fraud and Cyber Convergence Guide.
Where identity fits
A shopping agent is a non-human identity acting for a person. The safest designs give it its own credential, scoped to a purchase, rather than lending it yours: a one-time token with an allowance, or a signed mandate. Merchants and payment providers should be able to tell an agent from its user and verify the user's approval. For employers, staff using agents with corporate cards create the same issue inside the business, so expense and procurement policies need an agent clause. See the Agentic Commerce Identity Guide and the AI Acceptable Use Policy Template.
Detection and measurement for awareness teams
- Briefing content: teach the five rules in the checklist below, with a screenshot of what a hidden-instruction attack looks like from the user's side (an agent doing something you did not ask).
- Signals to watch on corporate cards: purchases from new merchants at unusual hours, repeated near-identical orders, delivery address changes and orders just below approval limits.
- Customer support (retailers): script how to handle "my agent bought this" complaints and capture agent and token identifiers. See the Cybersecurity for Retail and Ecommerce Guide.
| Metric | Why it matters |
|---|---|
| Share of agent purchases made with capped or single-use payment methods | Measures bounded exposure |
| Share of agent purchases with explicit human approval | Tracks how much buying is unattended |
| Disputed or reversed agent purchases per 100 orders | Shows error and manipulation rates |
| Time from suspicious alert to agent access revoked | Limits debit liability and further loss |
| Staff completing agent-shopping awareness module | Coverage of the policy |
Common failure patterns
- Agent runs in the everyday browser: logged-in email and banking are reachable when the agent follows a hidden instruction, the scenario Brave demonstrated against Comet.
- Main debit card saved for the agent: losses come straight from the current account, and recovery is slower than with credit or virtual cards.
- Unattended mode with vague constraints: "buy a good laptop" with no price ceiling or merchant list lets a manipulated agent spend the whole limit.
- Alerts sent to an inbox the agent controls: the agent, or whoever steers it, can read and hide the warning emails.
- Installing an unofficial assistant: fake shopping assistants and extensions are a simple route to card theft.
- No record of the instruction: without the original request and approval screen, a dispute becomes your word against the merchant's.
Framework mapping
| Topic | Reference |
|---|---|
| Hidden instructions | OWASP LLM01:2025 Prompt Injection; MITRE ATLAS AML.T0051 LLM Prompt Injection |
| Agents with too much power | OWASP LLM06:2025 Excessive Agency |
| Personal data shared with merchants | OWASP LLM02:2025 Sensitive Information Disclosure |
| Scoped payment credentials | ACP delegated payment allowance; AP2 checkout and payment mandates |
| Awareness and policy | NIST CSF 2.0 PR.AT-01 (awareness and training) |
Practitioner checklist
- Use in-assistant checkout with delegated tokens or mandates rather than an agent driving your normal browser.
- Run agent browsing in a separate profile with no email, banking or work sessions logged in.
- Pay with a virtual, single-use or low-limit card, never your main debit card.
- Set price caps, allowed merchants and short expiry for any unattended buying.
- Require approval for every purchase and for any change to address, email or payment details.
- Send card alerts and order emails to an inbox the agent cannot read.
- Keep the instruction, approval screen and receipts until the return window closes.
- Know how to revoke the agent and cancel the card, and do it immediately if anything looks wrong.
Standards and references
- Agent Payments Protocol (AP2): specification and security and privacy considerations
- Agentic Commerce Protocol (ACP): specification and delegated payment RFC
- OWASP: Top 10 for LLM Applications 2025
- MITRE ATLAS: LLM Prompt Injection
- FTC: Lost or Stolen Credit, ATM, and Debit Cards
- Brave: Agentic Browser Security: Indirect Prompt Injection in Perplexity Comet
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Agentic Commerce Identity Guide · Agent Payments Protocols Guide · AI Browser Extensions Security Guide · Impersonation Scams Guide