Agentic Payments on UPI | Elacity
India will soon let AI agents pay on UPI without approving each transaction, guarded only by a spending cap. A cap limits the loss but never checks whose order it was. Here is the better model.
Agentic Payments Are Coming to UPI. A Spending Limit Is Not a Safety Model.
You are about to hand an AI agent a standing line to your bank account. India's payments network is preparing to let agents move money on UPI without asking you to approve each transaction, and the only thing between your balance and a bad instruction is a number you picked in advance.
That number is a cap, not a control. It decides how much can leave. It says nothing about who really gave the order, or whether the request that just triggered a payment came from you or from a poisoned message your agent read on the way to the checkout.
What India actually built
Reports say the National Payments Corporation of India will preview a framework at the Global Fintech Fest in Mumbai, running September 9 to 11, that lets AI agents make small UPI payments on your behalf without per-transaction approval. It leans on two features UPI already has: UPI Circle, which lets an account holder delegate payment authority to a secondary party, and Reserve Pay, which blocks a pool of funds once for many future debits. Groceries and other low-value, repeat purchases are the first use cases.
This is real progress, and India is early. Payment companies elsewhere have shipped agent frameworks already: Mastercard launched a protocol for agents to transact, and agentic AI now has its own payment standards. Putting one on a national retail rail used by hundreds of millions is a bigger act of nerve. The design is careful. The problem is not the ambition. It is the safety model underneath it.
Why a spending cap is the wrong safety model
Delegating on UPI Circle hands the agent a standing authority. Within your preset limit, it can pay. The cap bounds the damage. It does not decide whether any single payment should happen at all, or whether the agent asking for it is still doing your bidding.
That gap matters because agents do whatever their inputs tell them to. Researchers keep showing that an agent reading an attacker's text can be talked into acting against you. A cap of a few thousand rupees does not care that the instruction came from a spoofed merchant page or a prompt buried in a product listing. It checks the amount and nothing else. Inside the limit, the fraud clears like a real purchase.
A standing authority is also a standing secret. Whatever token lets the agent pull funds has to sit somewhere between uses, and anything that sits still can be copied. We have watched this exact failure before: handing an agent a permission it can replay is not the same as one you can enforce. The lesson repeats because the architecture repeats.
The fix is a capability the agent uses but never owns
Elacity starts from a different rule. An agent should be able to act for you without ever holding power it can be tricked into misusing, and without holding a secret anyone can steal. Visa let strangers transact without trusting each other; Elacity lets humans and AI agents compute together without surrendering their keys. The hard part of that, a key that works without being held, already ships today. The agent that spends for you at UPI scale is the direction we are building toward, and the primitive it needs is done.
1. A key used, never owned
The key that signs a payment is never handed to the agent. It is reconstructed for a single transaction inside a sealed sandbox, exists in the clear for a fraction of a second, is welded to that one action, then wiped. The secret is split across independent machines that each re-check your on-chain rights before releasing a share, so no single operator, Elacity included, ever holds the whole of it. The agent gets the outcome, a completed payment, never a key it could reuse tomorrow. You can own without ever storing a secret, and so can the agent acting for you.
2. Narrow, revocable, expiring permission
A preset limit is one blunt dial. A capability is a specific grant: this agent may pay this counterparty, up to this amount, until this hour, for this purpose, and nothing else. Nothing it does touches your funds until you grant that narrow permission, and the instant you revoke it the action stops mid-flight. The system fails closed, not open. Every grant and every revocation is a signed, audited act, so you can see exactly what your agent was allowed to do and when. Humans and AI move through the same gate, so the rule that scopes an app on your machine is the rule that scopes an agent.
3. Payment and ownership settled in one act
A cap answers how much. It never answers what you got. When an agent buys a dataset, a track, or a license for you, the thing it paid for should arrive as property you can prove and control, not a copy dropped in a folder. That is the ownership half of agentic commerce, and it settles in the same motion as the payment rather than getting bolted on afterward.
India's engineers did the hard part: making agent payments usable at national scale. The missing piece is not a higher cap or a smarter fraud filter layered on top. It is an authority an agent can use and never keep, running on a machine you own. Set the terms, hand over a capability instead of a key, and take it back the moment it stops serving you.
See what an owned computer does with an agent's authority: Get ElastOS.