India's Agent Trust Layer: The Mandate Gap Nobody Has Filled

India already has a law that says an AI agent's purchase is the user's act. What it does not have is a way to prove what the user actually authorised. Every mandate scheme built so far is operated by a party with an interest in the outcome. That is the unfilled space, and it is narrower and more defensible than the one most people are describing.

This piece makes a specific claim: the need is not for a mandate. Mandates are arriving from every direction, and they are serious engineering. The need is for a mandate whose keeper is independent of the party being checked.

---

The Law Already Works. The Evidence Does Not.

Start with the strongest fact available, because the rest of the argument stands on it.

India's Information Technology Act 2000, section 11(c), reads:

"An electronic record shall be attributed to the originator (a) if it was sent by the originator himself; (b) by a person who had the authority to act on behalf of the originator in respect of that electronic record; or (c) by an information system programmed by or on behalf of the originator to operate automatically."

Section 10A adds that a contract formed by electronic communication of proposals and acceptances "shall not be deemed to be unenforceable solely on the ground that such electronic form or means was used."

An agent's purchase is already, by statute, the user's act. Not speculatively. Not pending a framework. Today.

Two limits to state plainly, because precision is what earns trust with the reader who matters.

First, the Indian Contract Act 1872 does not apply here. Section 182 defines an agent as "a person employed to do any act for another." A machine is not a person. Attribution for an automated system runs through IT Act s.11(c), not through agency law.

Second, and this is the entire problem: s.11(c) attributes the act. It says nothing about how anyone proves what the system was "programmed by or on behalf of" the originator to do. The evidence of what the user authorised is held by the party that built the agent. Nobody has said that is a problem yet.

That is the spine of this piece. The statute works. The proof architecture does not exist.

---

The Field Is Moving

Six months ago it was credible to say no one had built a mandate for agent-led payments. That is no longer true, and the pace is instructive.

Google's AP2 (Agent Payments Protocol), announced in September 2025 with more than sixty partners including Mastercard, American Express, PayPal, Coinbase, Adyen, Worldpay, UnionPay and JCB, uses cryptographically signed mandates to carry authorisation and accountability between agents and payment systems. Each mandate, whether Intent, Cart or Payment, is a W3C Verifiable Credential: tamper-evident, signed, portable, revocable. The constraint vocabulary is genuinely good: amount ranges, allowed payees, allowed instruments, execution-date windows, recurrence budgets.

In India, Pine Labs launched P3P in June 2026, a UPI-native agent payment protocol built on One Time Mandate and Reserve Pay with its own identity and spend-control layer. Both are serious pieces of engineering, and both point at the same conclusion: the mandate, not the payment, is where agentic commerce actually gets decided.

Others in the field: Mastercard Agent Pay (29 April 2025), Visa Intelligent Commerce (30 April 2025), Coinbase x402 (6 May 2025), OpenAI and Stripe's Agentic Commerce Protocol (29 September 2025).

The market is forming. The question worth asking is not whether mandates will exist. They already do. The question is what they leave unresolved.

---

What India Has Built So Far

October 2025: the first pilot

On 9 October 2025, Razorpay, NPCI and OpenAI announced a pilot called Agentic Payments, letting ChatGPT users complete UPI purchases in-chat. Built on UPI Circle and UPI Reserve Pay. Bank partners Axis Bank and Airtel Payments Bank. BigBasket among the first merchants.

Sohini Rajola, Executive Director Growth at NPCI, on record: "Agentic Payments marks an important step in India's digital payments journey, where AI and UPI converge to make transactions more intuitive, intelligent, and inclusive."

February 2026: expansion to Claude

On 20 February 2026, at the India AI Impact Summit in New Delhi, Razorpay and NPCI announced agentic UPI payments inside Claude, with Zomato, Swiggy and Zepto as launch merchants, running on UPI Reserve Pay in a limited pilot.

Sohini Rajola, NPCI, on record: "Users can give consent once and allow intelligent systems to transact on their behalf."

A precision that matters: Anthropic is not a named partner in any source for the UPI integration. Anthropic's own India announcement four days earlier, on 16 February 2026, names Razorpay only for internal AI use and Swiggy only for MCP-based ordering. It does not mention NPCI, UPI, agentic payments, Zomato or Zepto. The correct attribution is Razorpay and NPCI, on Claude. Both events are pilots with limited user groups.

July 2026: the UAP reporting

Business Standard reported on 9 July 2026, citing four people aware of the matter, that NPCI is developing a Unified Agent Protocol designed to "create a trusted, common, interoperable infrastructure through which AI agents can be registered, verified, and authorised to transact across the UPI ecosystem." NPCI did not comment: "An email sent to NPCI on July 2 seeking comments for the story remained unanswered till press time." RBI approval is reported as required.

The load-bearing sentence for our argument, verbatim from Business Standard: "NPCI wouldn't get the data on what has been bought. Its job is to ensure trusted agents and it will hold logs of agentic transactions to just verify that trust."

Every downstream mention, from Outlook Business to siliconindia to Medianama, traces to this one story. There is no independent confirmation and nothing further in the six weeks since. The final framework is yet to be announced. No timeline has been given.

The regulatory record

As of August 2026, neither NPCI nor RBI has published any circular, framework, draft or formal position on AI agent payments, agent identity, or delegated agent authority.

There is no official Indian position on any of this. That is not a criticism. It is the context in which every claim in this space should be read.

---

UPI Reserve Pay: What It Is and What It Is Not

Reserve Pay is a consumer-facing enhancement of UPI Single Block Multiple Debits. The user blocks funds in their own account against a mandate; the merchant debits against that block one or more times. Person-to-merchant only.

Predecessor circular: NPCI/UPI/OC.No.200/2024-25, dated 31 July 2024. Reserve Pay was unveiled by RBI Governor Sanjay Malhotra at Global Fintech Fest 2025 in Mumbai, early October 2025.

There is no documented NPCI support for a buyer-side agent initiating the block. Every NPCI-sourced description has the user creating it. Razorpay's agentic pilots operate the agent within a user-created reserve; there is no published NPCI provision for an agent to create the reserve itself. Medianama hedges it as Reserve Pay "appears to be the backbone for agentic payments."

---

The Basket Problem

This section is checkable, it corrects a thing most people assume, and it exists nowhere else in this combination.

How payment messages are structured

The UPI ReqPay message carries transaction-level data only: a transaction ID (35 characters), RRN (12 digits), transaction type, timestamp, a single aggregate amount, currency (INR only), a note/remarks field of 1 to 50 characters, payer VPA/name/account/IFSC/MPIN, payee VPA/name/account/IFSC, merchant ID and category code. The addInfo fields exist but are reserved. There is no SKU, item, cart, quantity or invoice-line element in a UPI payment.

This is not a limitation of any particular payment gateway. It is how the UPI message specification is designed. The rail carries the total. It does not carry the basket.

Where line items live in the stack

Payment gateway order APIs follow the same structure. The standard Create Order call accepts amount, currency, receipt, notes and a few control flags. No line_items, no cart, no SKU, no product field. The notes object is capped at 15 key-value pairs of 256 characters each, which is not a viable itemisation channel.

Line items exist at a different layer of the stack. Razorpay's Magic Checkout, for example, treats line_items as a mandatory parameter, with the full item shape including sku, price, offer_price, quantity, name and image_url. Their documentation is explicit: "To ensure the order is considered as a Magic Checkout order, you must pass this parameter. Otherwise, it will default to Standard Checkout order." That is a product design decision about where itemisation belongs, and it is the right one for checkout optimisation.

But it means the payment rail and the standard settlement layer carry a single number. Nothing in either captures what was in the basket.

What this means for agents

When an agent places a UPI order, the payment rail records a single number: the total. Nothing in the settlement layer captures what was in the basket, what the user asked for, or whether the items match the instruction.

The mandate says "buy groceries under Rs 500." The agent buys Rs 480 of the wrong groceries. The payment settles. The UPI message says Rs 480. Nothing in the message, the order, or the settlement record distinguishes a correct basket from a wrong one.

This is the evidence problem that s.11(c) leaves open. The statute attributes the act to the user. The rail carries no record of what the user intended the act to be.

---

The Margin Arithmetic: Why Wrong Orders at Machine Speed Matter

Not returns. Not RTO. Spoilage.

The instinct is to reach for return-to-origin data here. That instinct is wrong, and following it would have produced the weakest sentence in this post.

RTO is a failed-delivery phenomenon requiring multi-day transit, an absent buyer, and a cooling-off window. A ten-minute delivery to a customer watching the app cannot produce meaningful RTO. The structural reason is visible in the data itself: Shipway's FY25 shipment data shows RTO rising from 22% at 1-2 day delivery to 35% at 5+ days. Extrapolating that curve toward ten-minute delivery points toward near zero.

RTO kills D2C e-commerce. Quick commerce dies of a completely different wound. Both halves are sourced. Nobody else is drawing the contrast.

The D2C wound, for context

• 26% RTO rate on COD orders, under 2% on prepaid. Shipway ShipNotes, FY25 shipment data. COD is roughly a 13x multiplier on RTO risk.
• Seasonal swing for D2C brands: RTO approximately 39% at festive peak (November 2025), falling to approximately 21% by February/March 2026. Unicommerce India D2C Report 2026, covering April 2025 to February 2026, 6,000+ brands, 410 million shipments.
• Bain & Company's How India Shops Online 2026 notes quick commerce shows "lower reliance on cash-on-delivery compared to traditional e-retail," with an industry-wide "shift from cash-on-delivery to UPI at delivery."

The quick commerce wound: profit measured in single-digit rupees

Blinkit Q1 FY27 (quarter ended 22 July 2026): NOV Rs 17,132 crore, net AOV Rs 518, adjusted EBITDA Rs 102 crore, or 0.6% of NOV. Derived: approximately Rs 3.08 of adjusted EBITDA per order. 2,443 dark stores. Steady-state capex per store raised from Rs 1 crore to Rs 2.5 crore.

Blinkit Q4 FY26: NOV Rs 14,386 crore, 273.9 million orders, net AOV Rs 525, adjusted EBITDA Rs 37 crore, or 0.3% of NOV. Derived: approximately Rs 1.35 of adjusted EBITDA per order.

Swiggy Instamart Q4 FY26: GOV Rs 7,881 crore (+68.8% YoY), AOV Rs 700, contribution margin −1.8% of GOV (March 2026 monthly −1.1%), adjusted EBITDA margin −10.9%, segment loss Rs 858 crore, 1,143 dark stores. Derived: approximately −Rs 12.6 per order at contribution level. Still contribution-negative.

Dark store break-even, per Emkay Global: approximately 800 orders per day in tier-2 cities, approximately 1,300 in tier-1.

All per-order figures above are derived from disclosed aggregate totals. They do not appear in the companies' published results.

The best statistic in this piece

Blinkit lost 1.8% of NOV, approximately Rs 308 crore in Q1 FY27, to expired products, damaged goods, goods lost in transit and theft. Disclosed in Eternal's Q1 FY27 shareholder letter.

That inventory loss is roughly three times Blinkit's entire adjusted EBITDA of Rs 102 crore for the same quarter. Derived: approximately Rs 9.3 per order lost to spoilage against Rs 3.08 per order earned.

Caveat: the 1.8% appears in the shareholder letter, not audited statements, and has no prior-quarter comparative.

Ranked margin leaks in quick commerce: spoilage, then last-mile delivery cost, then dark store fixed cost, then discounting. Returns and RTO do not appear on the list.

The argument this actually supports

Not "agents will increase returns." That is unevidenced. The supportable version:

At Rs 1.35 to Rs 3.08 of profit per order, a merchant cannot absorb a new category of erroneous orders. An agent placing wrong orders does it at machine speed with no human noticing for hours. One bad rule, forty orders. The cost of a wrongly authorised agent order is not the RTO freight. It is that it lands in a business where a single spoiled basket already erases the profit on three correct ones.

No data exists on agent order error rates anywhere in the world. That honesty is worth more than a fabricated number.

---

The Profile Problem: Existing Duties with No Answer for a New Buyer

An agent buying on a user's behalf cannot satisfy certain seller obligations that exist today, and this requires no new regulation to be a live problem.

COTPA s.6: the tobacco example

The Cigarettes and Other Tobacco Products Act 2003, section 6: "No person shall sell, offer for sale, or permit sale of, cigarette or any other tobacco product (a) to any person who is under eighteen years of age, and (b) in an area within a radius of one hundred yards of any educational institution."

In practice, the only mechanism for this at online checkout is a self-declaration checkbox. An agent does not declare. It clicks. The seller's statutory duty under s.6 does not disappear because a machine ticked the box. There is nobody present to self-declare, and the penalty under s.24, a fine of up to Rs 200, is not what motivates. The licence is.

No statutory age verification at online checkout exists in India. The duty under COTPA s.6 falls on the seller with no prescribed verification method. The Consumer Protection (E-Commerce) Rules 2020 impose disclosure and grievance duties, not age verification.

Alcohol: a State subject

Alcohol is governed by each state's excise act under Constitution Seventh Schedule List II Entry 8. Online sale and delivery is permitted only where a state's excise rules allow it, and the list of such states has changed repeatedly since 2020.

E-cigarettes: the one outright prohibition

E-cigarettes and ENDS are prohibited including online sale, under the Prohibition of Electronic Cigarettes Act 2019.

DPDP: important framing correction

The Digital Personal Data Protection Act 2023 requires verifiable parental consent before processing a child's personal data (s.9). The DPDP Rules 2025 were notified on 13 November 2025, but Rule 10 on verifiable parental consent commences only on 13 May 2027, eighteen months after notification. It is not yet in force.

Rule 10 verifies the parent for consent to data processing. It is not an age gate on purchases. The two should not be conflated.

The supportable version is simpler and better: an agent buying on a user's behalf cannot satisfy a seller's COTPA s.6 duty, because the only mechanism in use is a self-declaration checkbox and there is nobody present to declare. That is an existing statutory duty with no answer for a new buyer type. It needs no new law to be a live problem today.

---

The Question of Independence

Pull the threads together.

The statute (IT Act s.11(c)) says the agent's act is the user's act. The payment rail (UPI) carries no record of what the user intended the act to be. The regulatory record is blank. The merchant margins are measured in single-digit rupees per order, against spoilage losses three times larger than profit. And existing statutory duties like COTPA s.6 have no mechanism for a non-human buyer.

A mandate has to be held somewhere. Today the candidates are the network, the acquirer, or the company operating the agent. Each is a competent custodian. None is a disinterested one, because each has a commercial relationship with the outcome being recorded. That is not a criticism of any of them. It is the same reason a company does not audit its own books.

Every piece of this picture is someone else's problem. The basket data is the merchant's problem. The mandate is the network's problem. The statutory duty is the seller's problem. The missing evidence is the user's problem. What is missing is a party for whom the integrity of the record itself is the problem, one that has no interest in any particular transaction settling.

A mandate signed by the network is a promise the network made about a transaction the network settles. A mandate signed by the acquirer is a promise the acquirer made about a transaction the acquirer processes. A mandate signed by the operator is a promise the operator made about an agent the operator deployed.

None of these is wrong. All of them are self-referential. The piece that is missing is a mandate whose keeper does not benefit from the transactions the mandate authorises. An entity that records what the user consented to, what the agent was instructed to do, and what the agent actually did, and has no economic interest in the distance between those three things.

---

Where This Goes

Business Standard's reporting, if accurate, describes a UAP that would "verify whether an AI agent is authorised to act on a user's behalf, define the limits of that authority, and establish accountability if those limits are exceeded." The same reporting quotes that "NPCI wouldn't get the data on what has been bought. Its job is to ensure trusted agents and it will hold logs of agentic transactions to just verify that trust."

That is a design choice about where the trust boundary sits. It is not yet a published protocol, and it is not yet approved by RBI. The final framework is yet to be announced.

Whatever form it takes, the structural question will remain the same: who holds the record of what the user authorised, and do they have an interest in the answer?

If the entity holding the mandate is the same entity settling the payment, the mandate is an invoice, not a constraint. If the entity holding the mandate is the same entity that deployed the agent, the mandate is a self-assessment, not an audit. If the entity holding the mandate is independent of both, the mandate is evidence.

The technology for signed, portable, cryptographically verifiable mandates exists. AP2 proved that. The infrastructure for UPI-native agent payments is being piloted. Razorpay and NPCI proved that. The statute that makes the agent's act legally attributable to the user exists. IT Act s.11(c) proved that.

The thing that does not yet exist is the independent layer that binds them: the entity that can tell a regulator, a merchant, and a user exactly what was authorised, without having been the one doing the authorising.

That is not a technology problem. It is a trust architecture problem. And it is the one worth solving.

---

Key Takeaways

• India's IT Act s.11(c) already attributes an agent's transaction to the user. The legal footing exists. The evidentiary infrastructure does not.
• The UPI payment message carries no item-level data. Proving what an agent was authorised to buy, versus what it actually bought, requires a record that does not exist in the payment rail.
• Mandates are arriving from every direction: AP2 with sixty-plus global partners, P3P on UPI, and more. The mandate is no longer the missing piece. Independence is.
• At Rs 3.08 of adjusted EBITDA per order, quick commerce cannot absorb a new category of erroneous orders placed at machine speed.
• As of August 2026, neither NPCI nor RBI has published any framework, circular or formal position on AI agent payments, agent identity, or delegated agent authority.
• An agent buying on a user's behalf cannot satisfy a seller's existing statutory duty under COTPA s.6, because the only mechanism in use is a self-declaration checkbox and there is nobody present to declare.

FAQ