Delegated Commerce: Can AI Agents Safely Pay on Behalf of Users?

Imagine asking an AI assistant to restock your household essentials, compare prices across trusted stores, and complete the purchase when the total is below ₹2,000. You do not want to approve every item individually, but you also do not want software making unlimited decisions with access to your money.

That is the promise—and the challenge—of delegated commerce: allowing a person to authorize another party, service, or AI agent to take defined steps in a purchase, potentially including payment.

The idea is not entirely new. India’s UPI Circle provides a useful example of how payment delegation can be structured around consent, limits, and visibility. AI agents introduce a different set of risks, however, because they can interpret instructions, interact with websites and APIs, and make decisions across multiple steps.

For businesses building AI-powered shopping and payment experiences, the central question is not simply whether an agent can pay. It is whether the agent can act within a clear, verifiable, and revocable scope of authority.

What Is Delegated Commerce?

Delegated commerce occurs when a user gives another actor permission to perform some or all of a buying journey on their behalf. The delegation may cover product discovery, comparison, cart creation, checkout, or payment.

There are several levels of delegation:

Discovery: The agent searches for products and recommends options, but the user makes the purchase.
Preparation: The agent builds a cart or prepares an order, then asks the user to confirm.
Conditional purchasing: The user sets rules—such as a maximum price, approved merchants, or product requirements—and the agent can complete qualifying purchases.
Ongoing delegation: The agent handles recurring or routine purchases within a defined budget and scope, with monitoring and an option to revoke access.

These levels should not be treated as interchangeable. Permission to compare products does not automatically mean permission to place an order, and permission to place an order does not necessarily mean permission to move money without further checks.

UPI Circle: A Practical Model for Payment Delegation

The National Payments Corporation of India (NPCI) describes UPI Circle as a way for a primary user to extend payment authorization to a secondary user, subject to limits and risk controls. Depending on the supported implementation, the primary user can choose between partial delegation, where each payment requires approval, and full delegation, where the secondary user can transact within a predefined limit.

This model addresses a familiar real-world need: a parent may want to give a child controlled spending access, or a household member may need to make routine purchases without asking for approval every time. The account holder retains oversight while another party gains bounded authority.

NPCI’s published UPI Circle information also describes a direction toward payments from trusted devices or software, including use cases such as purchases through AI chatbots. NPCI materials have described these IoT/software payment capabilities as being introduced on a limited or pilot basis, so availability and applicable controls should be checked against current official guidance rather than assumed to be universal.

The important lesson is the design pattern, not that a human delegate and an AI agent are identical. A person can understand context and be held accountable in ways that software cannot. An AI agent may misinterpret an instruction, follow malicious content on a website, choose a misleading listing, or continue acting after circumstances change. AI-led payment delegation therefore needs additional controls around identity, task scope, tool access, and decision-making.

For the latest feature details and limits, consult the NPCI UPI Circle overview.

How Should an AI Agent Be Authorized to Pay?

A trustworthy system should separate the user's intent from the agent's technical ability to initiate a transaction. Connecting an agent to a payment method should not, by itself, grant unrestricted spending authority.

1. Make consent explicit and specific

Before delegation begins, the user should be able to see what the agent is allowed to do. A meaningful authorization could specify:

Which task the agent may perform, such as buying a named item or replenishing household supplies.
Which merchants or merchant categories are allowed.
The maximum amount per transaction and over a defined period.
Whether substitutions, add-ons, tips, delivery fees, or recurring charges are permitted.
When the agent must stop and ask for confirmation.
How long the authorization remains active.

A vague instruction such as “handle my shopping” leaves too much room for interpretation. A clearer instruction might be: “Buy the listed essentials from these approved merchants, keep the total under ₹2,000 including delivery, do not substitute products, and ask me before placing an order if the price or availability changes.”

2. Use spending guardrails that match the task

A single overall budget is useful, but it may not be enough. An AI agent could stay under a monthly cap while making an inappropriate purchase or splitting a large order into multiple transactions.

Useful guardrails include:

Per-transaction caps: Set a maximum amount for any single payment.
Aggregate limits: Track total spending over a day, week, or month.
Merchant restrictions: Allow only approved stores or verified payment recipients.
Category restrictions: Permit groceries but block unrelated purchases.
Item-level rules: Specify acceptable brands, quantities, sizes, or substitutions.
Velocity controls: Flag repeated purchases or unusually frequent transactions.
Step-up approval: Require the user to approve transactions that cross a threshold or fall outside the expected pattern.

The system should calculate the amount that will actually be charged, including taxes, delivery fees, and other disclosed costs. If the final total exceeds the user's limit, the agent should pause rather than silently expand its authority.

3. Keep authentication and payment authorization distinct

Logging in proves something about a user or session; it does not necessarily prove that a particular purchase is authorized. Likewise, an agent's API access should not be treated as blanket consent to every action it can technically execute.

Payment platforms should use established authentication and payment authorization controls, and should make the authorized amount, recipient, and relevant transaction details clear before approval where required. Sensitive credentials such as UPI PINs, passwords, and one-time passcodes should not be exposed to an AI model or stored in agent memory. Payment credentials and transaction execution should remain inside appropriately secured payment components.

The exact authentication and regulatory requirements depend on the payment method, provider, jurisdiction, and transaction type. Businesses should confirm the applicable requirements with their payment partners and legal or compliance teams rather than assuming that a conversational instruction replaces them.

4. Make every action visible and auditable

Users should be able to review what the agent did and why. A useful activity record could show the instruction received, products considered, final item selected, merchant, total amount, authorization rule applied, and transaction status.

Notifications should distinguish between an agent preparing a cart, requesting approval, initiating a payment, and receiving confirmation that the payment succeeded. A successful checkout page or an agent's own statement is not sufficient evidence that a payment settled.

Clear records also help customer support teams investigate disputes, identify suspicious activity, and determine whether the system followed the user's authorization.

5. Make revocation immediate and practical

Delegation must not be permanent by default. Users should be able to pause or revoke an agent's authority, disconnect payment access, remove trusted devices, and review active permissions without navigating an unnecessarily complicated process.

Systems should check that authorization is still valid at the time of payment—not only when the agent starts a task. They should also define what happens if a user revokes access while an order is being prepared or a payment is in progress. Revocation cannot necessarily reverse a transaction that has already completed, so the interface must explain the difference between stopping future actions and resolving an existing payment.

The Special Risk of AI Agents: They Can Be Manipulated

Traditional delegated payment systems usually operate within a relatively predictable workflow. AI agents may read product pages, emails, search results, documents, and other content that contains misleading or malicious instructions. An agent could be tricked into changing a delivery address, selecting a fake merchant, adding unwanted products, or disclosing sensitive information.

This is why payment safety cannot depend only on asking the model to “be careful.” It requires technical boundaries around what the agent can access and execute.

A safer architecture should include:

Least-privilege access: Give the agent only the tools and permissions required for its assigned task.
Trusted payment interfaces: Use controlled payment APIs or approved checkout flows rather than exposing raw credentials.
Independent policy enforcement: Check limits and merchant rules in a deterministic layer outside the model's free-form reasoning.
Untrusted-content isolation: Treat webpages, emails, and product descriptions as data, not as instructions that can override the user's rules.
Transaction binding: Bind approval to relevant details such as the merchant and amount, so a material change triggers a new check.
Risk-based escalation: Require stronger verification or human approval for unusual, high-value, or irreversible actions.
Monitoring and incident response: Detect anomalous behavior, retain appropriate audit logs, and provide a way to suspend the agent quickly.

These controls should be tested against realistic failures, including prompt injection, duplicate orders, price changes, compromised merchant accounts, expired permissions, and network retries that might otherwise trigger repeated payments.

A Practical Example: An AI Grocery Assistant

Consider a user who authorizes an AI assistant to purchase weekly groceries.

The user sets the rules: A budget of ₹2,000 per order, approved merchants only, no alcohol or non-grocery products, and no substitutions without consent.

The agent prepares the order: It compares prices and availability, builds a cart, and calculates the total including delivery charges.

The policy layer checks the cart: It verifies the merchant, categories, item rules, final amount, remaining budget, and whether the authorization is still active.

The agent either proceeds or pauses: If the cart meets every condition and the payment setup supports the authorized flow, it can continue within that scope. If the total is ₹2,120, a product is substituted, or the merchant is not approved, it must request a decision instead of proceeding.

The platform records the result: The user receives a receipt or clear failure notice and can inspect the transaction history, adjust the rules, or revoke future purchasing authority.

This example illustrates the intended control model; whether a particular platform can execute the payment autonomously depends on its payment integrations, authorization model, and applicable rules.

Who Is Responsible When Something Goes Wrong?

Delegated commerce creates shared responsibilities, but responsibility should not become ambiguous.

Users define the intended task and review the permissions they grant.
AI providers and agent developers design the agent's behavior, tool access, safeguards, and failure handling.
Merchants provide accurate product, price, availability, and order information and protect their checkout systems.
Payment providers and financial institutions operate within their payment, authentication, fraud-control, and dispute-handling obligations.
Platforms integrating the experience must make authorization understandable, enforce agreed limits, preserve useful records, and provide accessible support.

Contracts and user interfaces should explain how disputes, refunds, unauthorized transactions, and service failures are handled. The legal allocation of liability varies by jurisdiction and payment arrangement; it should not be left to assumptions about whether the AI, merchant, or user was “in control.”

A Readiness Checklist for Businesses

Before enabling AI agents to make purchases, product and risk teams should be able to answer these questions:

Can the user understand and approve the exact scope of delegation?
Are transaction, category, merchant, and time limits enforced outside the language model?
Are credentials protected from the model and from untrusted content?
Does a change in amount, merchant, item, or delivery details trigger the right checks?
Can the user see a reliable record of each action and payment status?
Can the authorization be paused or revoked, and is that state checked before execution?
Have duplicate payments, prompt injection, compromised tools, and failed checkout flows been tested?
Are customer support, refunds, disputes, and incident response clearly defined?
Have the relevant payment provider, security, privacy, and compliance requirements been reviewed?

If these questions cannot be answered confidently, the safer first step is to let the AI research and prepare purchases while keeping final payment approval with the user.

Conclusion: Trust Must Be Designed Into Delegated Commerce

AI agents could make online shopping and routine purchasing more convenient by taking on repetitive work and acting on clearly stated preferences. But when an agent can spend money, convenience must be balanced with consent, accountability, and technical enforcement.

UPI Circle offers a useful reference point for bounded delegation: a user grants authority, sets limits, and retains visibility and control. AI agents require that foundation plus stronger safeguards against manipulated instructions, unexpected decisions, and misuse of software permissions.

For businesses, the path forward is incremental. Start with discovery and cart preparation, introduce conditional purchasing with narrow limits, and expand autonomy only when authorization, monitoring, revocation, and incident handling have been tested. The goal is not to make an AI agent powerful enough to buy anything. It is to make the agent dependable enough to do only what the user actually authorized.

The future of delegated commerce will depend less on whether AI can complete a checkout and more on whether every transaction stays within a user's clearly defined boundaries.

Further reading: NPCI UPI Circle and NPCI UPI information and circulars.