Ask Kabbalist

You tell your AI browser to find the cheapest 65-inch TV under Rs 60,000 and buy it. It finds one in about eleven seconds. Then it stops. Not because Amazon blocked it, and not because a judge did. It stops because nothing in India's payment plumbing knows how to let a piece of software hold your wallet.

Why It Matters

On 9 March 2026, a federal judge in the Northern District of California ordered Perplexity to keep its Comet browser off Amazon. On 4 August the Ninth Circuit vacated that order in Amazon v. Perplexity, No. 26-1444, and the reasoning is the part worth keeping. Where the AI company's servers never speak to the retailer directly, and every request routes through the shopper's own machine, the panel held that it is the shopper who "accessed" Amazon's computers under the Computer Fraud and Abuse Act. Not the software vendor.

Read the coverage and you would think agentic shopping just won outright. It didn't, quite. The panel left Amazon's contract and tort claims standing, terms-of-service breach included, and went out of its way to say it was not foreclosing liability for agents with greater autonomy, or for designs where the vendor's own servers hit the retailer. So the decision protects one narrow shape: a local agent driving your session, on your hardware, with your login. Build it any other way and you are back in front of a judge with worse facts. There is a second thing the ruling did not do. It did not stop Amazon from blocking agents by other means. Nothing in the opinion obliges a retailer to serve a request it can detect and refuse, and detection is a product problem rather than a legal one. A platform that loses on the statute can still rate-limit, fingerprint, challenge or quietly terminate the account, and none of that needs a judge's permission.

None of which is why your agent stalls at checkout in Bengaluru. The Reserve Bank of India's Digital Payments E-Mandate Framework, in force since 21 April 2026, requires your issuer to notify you at least 24 hours before any recurring debit lands. Sit with that for a second, with an agent in mind. The one rail built for automatic payments comes with a mandatory day of warning attached. It is the same instinct now shaping how platforms decide what software may act on your behalf, applied to money instead of apps, and it lands harder here. E-mandates were designed around a repeating charge whose amount and merchant you already know, on a date fixed well in advance. An agent's entire value is the opposite of that: an unpredictable amount, at a merchant you have never used, on the day it finally finds the thing. The rail and the use case were built for different worlds.

Four numbers frame the standoff: how long the ban actually held, what the retailer stands to lose, how fast agent buying is climbing, and how much of the open web is already machine traffic. Together they explain why Amazon spent five months fighting this, and why losing once has not ended it.

Take the order growth. Shopify's second-quarter 2026 earnings set it against a figure that matters more: 75% of AI-attributed purchases fell outside the company's top hundred product categories. Agents are not winning the things people already know how to buy. They are finding the awkward, badly-named, three-pages-deep thing you would have given up on by the second search.

Three Routes, One That Pays

So where does this leave an Indian shopper who actually wants the thing? Three routes exist right now, and the gap between them is not about how clever the model is. It is about who holds the authority to move money and who answers when the money moves wrongly. The third column deserves a note, because it is the one people picture when they hear the phrase. A delegated-payment agent is not an agent holding your password. It is an agent holding its own credential, one your bank recognises as separate from you, spending inside limits you fixed beforehand, leaving a trail that records which instruction came from a human and which from software. That is a great deal of new infrastructure, and not one piece of it is a model-quality problem.

Notice what the table does not contain. There is no column where an agent both chooses freely across the whole market and pays without you. That combination is the product everyone is describing, and in India it currently exists nowhere. The court fight was about the first half. The second half is a payments question, and payments questions in this country are settled by the regulator, not by the Ninth Circuit. It is tempting to read all this as a delay, as though the parts are on order and the launch is a scheduling matter. That reading is too generous. Granting payment authority to a non-human actor is a genuinely hard design question, and the countries working on it are not converging on a shared answer.

Friction Points

India does have an answer in progress. Business Standard reported in July 2026, citing industry sources, that the National Payments Corporation of India is building a Unified Agent Protocol to authenticate agents and set transaction limits without rebuilding UPI underneath. That is the right shape. It is also, as of today, a reported development rather than an announced product: no official NPCI statement, no timeline, no pilot, no published limits. The protocol is real, or at least the consultation is; the protocol itself is still slideware.

Which brings up the thing that irritates me about the current commentary. Specific per-transaction caps have been circulating as though they were policy. They are not. They come from one writer's proposal about what NPCI ought to do, and they have been repeated until they read like a specification. If you are planning around numbers nobody at the regulator has published, you are planning around fiction, and the correction will be expensive.

Then there is the hole nobody wants to own. An agent buys the wrong size, the wrong variant, the wrong seller. Under a card payment you dispute it. Under an agent-initiated debit, who is the counterparty: you, because a court just said the agent is your hands, or the vendor, whose model picked the listing? Reporting on the protocol work concedes that chargeback and dispute mechanisms will need to evolve. That concession is doing a lot of work. The same framework already obliges the issuer to send a post-transaction notification carrying its grievance redressal details, which tells you plainly how the regulator pictures recourse: a named human at both ends of every debit. An agent-initiated purchase breaks that assumption at the first step, and no amount of protocol design makes the question of who authorised the spend disappear.

• Check where the agent actually runs. If it drives your browser on your machine, the Ninth Circuit's reasoning covers you. If it calls the retailer from a vendor's cloud, that protection was explicitly not extended.
• Read the retailer's terms before you point an agent at it. Contract claims survived this ruling untouched, and account termination needs no court at all.
• Keep the final confirmation yours. The moment you hand over the button, your chargeback story gets harder to tell.
• Treat any agent asking for a standing payment mandate as premature. Nothing in India authorises it yet.

Use an agent to shop, not to pay. Let it hunt and fill the cart, then check the total yourself and press the button with your own thumb. That is not caution for its own sake, it is the only configuration where you keep both the legal cover the Ninth Circuit just described and the dispute rights India's payment rules already give you. Revisit it the day NPCI publishes an actual specification. Until then, the agent works for you right up to checkout, and that is genuinely useful on its own.

Keep reading

• AI Browsers vs Chrome in 2026: Should You Switch Now
• AI Voice Cloning Scams in India: Your 2026 Survival Guide
• Figma AI vs Adobe Firefly vs Canva Magic Studio in 2026

A friend sends you an APK on WhatsApp. It is a small utility, the kind that never made it to Play because the developer could not be bothered with a store listing. You tap it, Android asks its usual question, you say yes, and it installs. That flow is changing, and most of the coverage has handed Indian readers the wrong date for it.

Why It Matters

Start with what the rule actually checks. Google is confirming who published an app, not what the app does. No code review, no content pass, no judgment on whether the thing is any good. It is a name-and-document check attached to a signing key, and the practical effect is that anonymous distribution stops being an option on certified devices. Whether you read that as overdue hygiene or as another gate on hardware you already paid for probably depends on how you felt when Apple kept self-service repair out of India using a similar safety argument.

India sits outside the first enforcement wave, and that is doing a lot of work in the coverage. Nothing on an Indian phone becomes uninstallable on 30 September. But look at which stores signed up: Google Play, Samsung's Galaxy Store, Xiaomi's GetApps, OPPO's App Market, vivo's V-Appstore, HONOR and Palm. That is nearly every app store that ships preloaded on a phone sold in this country. StatCounter put Android at 92.44% of India's mobile OS share in July 2026. When the rule does arrive here, it will not arrive at the margins.

The security case is real, and worth stating at full strength rather than waving at. Google's own Android Developers Blog post from 25 August 2025 said its analysis found over 50 times more malware from internet sideloaded sources than from apps available through Google Play. That is Google measuring its own platform, so read it with the appropriate squint, but a gap that size is not a rounding error. The counter-argument is not that the malware is imaginary. It is that identity checks catch the lazy operator and inconvenience the hobbyist, while the organised fraud rings buying stolen KYC documents in bulk carry on. Nobody has published a clean before-and-after on that yet, and until someone does, anyone claiming to know which way it nets out is guessing.

The waiting period is the number that changes behaviour, and not because it is long. It cannot be completed in the moment. Someone on a phone call telling you to install a file right now, this minute, before your account is frozen, has just been handed a delay he cannot argue you past. That is the same pressure pattern running through the AI voice cloning scams working Indian phone numbers, and a forced pause is a surprisingly rude interruption to it.

What Changes And What Does Not

Strip out the speculation and the rule set is small enough to hold in your head. Here is the whole thing, as published on Google's developer verification pages and its Android Developer Console help documentation.

Read that table twice and the shape of the thing shows up. Google did not close the door. It moved the handle to a place ordinary users will never look, added a delay to the one path that leads there, and left a developer tool untouched for people who own a laptop. Every one of those choices is defensible on its own. Together they describe a device that is a little less yours than it was.

Five stops on one line: the policy was announced in August 2025, verification opened to all developers in March 2026, the developer tools and the power-user install path shipped in August 2026, four countries hit enforcement on 30 September 2026, and everything else follows from 2027.

Friction Points

The advanced flow lives inside Developer options, which you reach by tapping the build number seven times. Google is not hiding it out of embarrassment. Burying it is the design. But it produces an odd result: the people most likely to need an app that never reached a store, a regional language keyboard, a niche utility, a local college's attendance app, are frequently the people least equipped to go digging through settings that warn them off at every screen.

Then there is the paperwork gap. An individual developer supplies a government ID. An organisation needs a D-U-N-S number from Dun and Bradstreet first, and that request can take up to 28 days to come back. For a two-person studio in Pune shipping a niche app, the fee is not the obstacle. The month of waiting and the registered-entity requirement are, and they arrive before a single line of the rollout touches India.

One more thing worth flagging, because it gets lost in the outrage cycle. The advanced path is not a one-time switch you flip and forget. Keep an eye on these before you decide the whole thing is overblown:

• The unverified-install setting can be enabled temporarily for seven days or left on indefinitely, so a temporary grant will lapse without warning you again.
• The adb route still installs unregistered apps, but it needs a computer, and plenty of Indian users have only ever treated a phone as their whole computer.
• Google's help text covers new installs only, and says nothing about apps already sitting on your device, so do not assume either outcome.
• Your phone brand's own preloaded store is on the participating list, so "I never use Play" is not the exemption people think it is.
• The rollout reaches handsets in stages, so two identical phones in the same house can behave differently this month.

So: nothing on your phone breaks next month. Use the time. If you rely on an app that lives outside a store, message the developer now and ask whether they have registered, because the answer in 2027 is going to be a lot less negotiable than the answer today. And if you are the sort of person who already keeps a second browser around rather than trusting one company's default, apply the same instinct here and get the file you actually care about onto your device while the door is still easy to open.

Related: How to use DigiYatra now that the face scan is mandatory for international flyers