DocsQuick StartAI News
AI NewsJD issues A2P2 protocol: Six spending tiers for AI
Product Update

JD issues A2P2 protocol: Six spending tiers for AI

2026-06-11T12:07:47.959Z
JD issues A2P2 protocol: Six spending tiers for AI

Today, JD.com released China’s first autonomous payment protocol for intelligent agents, A2P2, dividing AI payment permissions into six levels from L0 to L5. It focuses on addressing issues of authorization boundaries, identity verification, and fund segregation at the L3/L4 stages, aiming to fill the trust gap in the intelligent agent economy.

JD A2P2: When AI Starts Spending Its Own Money, Who Presses the Confirm Button

On June 11, JD dropped something pretty interesting — the Agent Autonomous Payment Protocol, abbreviated A2P2, billed as the first protocol in China specifically designed for autonomous payments by intelligent agents. In plain terms, it’s a set of rules for AI spending money.

This doesn’t need much background. Over the past year or so, from GPT to Claude to a slew of domestic Agent products, large models have long moved beyond “help you make a shopping list.” MCP, Computer Use, and various Agent frameworks are everywhere, but whenever players get to the “place order and pay” step, they hit the same wall: how to deduct funds? Who’s responsible? Who’s accountable if something goes wrong? OpenAI’s Operator still requires the user to click confirm, and the most awkward scene in Anthropic’s Computer Use demo was still human takeover at the payment stage. The more capable an intelligent agent becomes, the more obvious this wall is.

What JD wants to do this time is tear down that wall — but not by smashing it to pieces, rather by installing a door, fitting it with a lock, and handing out keys.

JD A2P2 Protocol L0-L5 Six-Level Classification Diagram

L0 to L5: A Grading Logic Borrowed from Autonomous Driving

The first eye-catching thing in the protocol is grading. A2P2 divides the autonomy level of agent payments into six tiers, a familiar idea — yes, it’s the same approach as L0 to L5 in autonomous driving. This analogy is actually pretty smart, because it instantly concretizes the abstract problem of “AI autonomy boundaries.”

  • L0: Every transaction requires manual confirmation; the AI is just a runner, no different from mainstream Agent shopping today.
  • L1-L2: AI can start doing some preprocessing, but payment deduction still depends on human approval.
  • L3: Within a single task scope, AI can initiate payment requests itself, which the system allows or blocks based on the user’s preset boundaries.
  • L4: Expanded authorization; as long as the amount, scenario, and payee are within presets, AI can continuously execute payments autonomously.
  • L5: Full delegation; AI has complete agency.

JD is fully aware that L5 is just a theoretical endpoint for now, nobody dares to use it outright. The protocol focuses on the hardest but most practical middle ground — L3 and L4. These two tiers correspond to scenarios that Agents most want to break through and that users most agonize over: ordering flowers, ordering takeout, renewing memberships, grabbing concert tickets — can it be done without me staring at the screen every time?

In my view, the greatest value of this grading lies not in technology, but in communication. It provides regulators, users, and developers with a shared vocabulary. In the future, discussing agent payments won’t require using a bunch of vague terms like “semi-autonomous,” “weak agency,” or “conditional triggers” — just say L3.

Mandate: Translating Human Words into Machine-Auditable Contracts

The core technical mechanism in the protocol is the Mandate — a task delegation credential. This solves the fundamental problem that natural language instructions cannot be verified.

Example: The user says to the Agent, “Spend no more than 200 yuan to order a bouquet for my friend.”

In traditional payment pipelines, this phrase is blurry at the system level. How much under 200? Does 199.99 count? Is shipping included? Does buying a vase along with flowers count? Every step is a loophole.

A2P2’s method is to first convert this natural language instruction into a machine-verifiable credential, structuring elements like maximum amount, category, payee, and validity period. Every time the agent initiates a deduction, the system reconciles against this credential: is the amount correct, the category correct, the merchant on the whitelist? If the Agent suddenly tries to buy a 300 yuan bouquet of roses, the request is directly rejected or bumps to the user for confirmation.

This isn’t a new design — it’s essentially formal modeling of payment intent, like conditional branches in smart contracts. But in the context of large-model Agents, it solves a very practical problem: LLM outputs are probabilistic, but money flows must be deterministic. The Mandate is the converter between the two.

ARI: Giving Agents an ID Card

A credential alone isn’t enough. Agent hijacking, prompt injection, contaminated runtime environments — these have been hot topics in security circles over the past year. A maliciously instructed Agent could still use a valid Mandate to drain your funds.

The second weapon JD built into the protocol is ARI (Agent Runtime Identity). The academic-sounding name boils down to one job: at the moment of deduction, tightly binding and verifying three things.

  1. Real user identity — whose pocket the money is ultimately coming from.
  2. Agent identity — whether the request comes from the exact Agent version originally authorized by the user, not a re-skinned counterfeit.
  3. Runtime environment — which device the Agent is currently running on, whether the environment is clean, and whether there’s malicious code injection.

All three must be satisfied for approval. Think of it as an “Agent-version” of three-factor authentication, with emphasis on “runtime.” It’s not a one-off check at the moment of authorization — every transaction verifies the current environment anew. This stops scenarios where “Agent was clean at launch yesterday, got hijacked today, and continues spending.”

In comparison, traditional payment models are like airport security — checked before entry, then free to move around. ARI is more like face-scanning at every boarding gate: inconvenient but safe.

ARI Agent Runtime Identity Three-Party Verification Mechanism Diagram

Funds Carrier Isolation: Giving Agents Their Own Wallet

The protocol’s third layer of defense is the “funds carrier isolation layer.” This approach is simple and very effective.

The logic is straightforward: Agents never touch your main account.

When a user authorizes an Agent, the system opens a “special account” with only enough funds needed, plus lots of hard constraints:

  • Single/total transaction amount limits
  • Allowed consumption scenarios (takeout? ride-hailing? shopping?)
  • Valid time window
  • Allowed payee whitelist

Even if the Agent is completely compromised, it can only move the budget in that special account; the main account remains untouched. The user can check anytime how much money is allocated under each Agent, where it’s spent, or revoke authorization in a click.

This resembles the “hot wallet/cold wallet” separation in Web3, or the “petty cash” mechanism in corporate finance. Bringing proven risk-control logic from the mature world into Agent scenarios is much more practical than inventing concepts from scratch.

Whose Problem Does This Solve?

By now, we should assess: is A2P2 a real need, or JD grabbing a standards foothold?

My judgment — real need, but for now the hand mainly plays in JD’s own court.

First, the real need side: For the agent economy to truly run, payment is unavoidable. OpenAI, Anthropic, and Google are all preparing big moves, but their paths lean towards “letting Agents access existing payment networks” — e.g., Stripe’s new Agent Toolkit, and hints from Visa and Mastercard about Agent-specific cards. JD’s path is different: redesigning from the protocol layer, bundling identity + authorization + fund isolation. In China’s integrated e-commerce payment landscape, this top-down design has advantages — JD is a goods platform, a payment provider (JD Pay), and makes its own large model (Yanxi). It can close the loop.

But conversely, this is also A2P2’s biggest weakness. For a protocol to become a standard, others must adopt it. If only JD’s Agents, JD’s payment, and JD’s goods can run on it, it’s not a protocol — it’s a product. The real test is later: will WeChat Pay and Alipay accept it? Will Agents from ByteDance, Alibaba, Tencent adopt it? Can cross-platform Mandate formats be unified? Without these solved, A2P2 can only circulate internally within JD.

Another point worth watching is alignment with international standards. Anthropic put out a draft on Agent Commerce in late 2025, mentioning authorization scope and runtime verification — thinking similar to ARI. If JD can make A2P2 open and contribute it to industry bodies (e.g., China Payment & Clearing Association, CAICT), then it can secure discourse power. Otherwise, it’s just another “industry first” PR phrase.

Practical Takeaways for Developers

Setting aside grand narratives, for developers making Agent products, A2P2 offers at least a few directly usable design patterns:

  1. Structure fuzzy instructions. Whether or not you call it Mandate, running LLM outputs through a formalized intent credential before downstream execution is a universal way to reduce hallucination risk. Not just for payments — any Agent action involving external side effects should be done this way.
  2. Runtime identity matters more than static identity. In an era full of prompt injection and jailbreaks, “who at authorization” is far less important than “who at execution and in what environment.” This idea can apply to many Agent security scenarios.
  3. Always give an Agent a limited sandbox. Whether funds, file systems, or API permissions, isolate where possible, restrict amounts where possible. The stronger an Agent’s abilities, the narrower the openings you give it.

Final Thoughts

By 2026, the intelligent agent economy is no longer a “can it be done” question, but a “dare we let go” question. The A2P2 protocol essentially addresses the latter — how to make users confident enough to hand their wallet to AI.

JD’s move is bold, at least domestically the first to systematically explain this issue. The L0-L5 grading, Mandate formalization, ARI runtime verification, and fund carrier isolation — the four-piece set is on the right track. What remains is seeing how the ecosystem connects, how regulators view it, and how competitors respond.

As a side note, developers building Agents and wanting to quickly compare which model is best for payment-driving Agents can use aggregation platforms like OpenAI Hub — one key to switch across GPT, Claude, Gemini, DeepSeek — saving the trouble of creating accounts and configuring keys for each. See which model’s “brain” is strongest by running a round.

The next question for the industry: when AI really can spend on its own, will the first person it “buys wrong” for step up and sue? That’s the real test A2P2 will face.

References

Related Articles

View All

Contact Us

We usually reply quickly during business hours

Scan WeChat

Support: Hub Assistant

WeChat ID: