Visa, Mastercard and Ant International each bring a different agent trust protocol to KYA

The example a dev.to developer post uses is a legitimate agent making an unauthorized charge ^[16]. The user's instruction is "Find a laptop under $1,500 with at least 16GB of RAM and buy it if you find a suitable one" ^[17]. The final price moves, and the agent attempts a $1,900 purchase. Identity verification passes, and the spending limit is a separate check that should not ^[7]. The attempt runs $400 over the grant, about 27 percent ^[8]. An identity check that waves the charge through is behaving as specified.

The post splits the problem into agent identity, user authorization, transaction intent, and execution plus monitoring ^[6]. Identity answers who the agent is. The other three ask which user or organization delegated the authority, what action that delegation covered, and whether the completed transaction stayed inside those limits ^[6][14].

Count the fields in the credential the post sketches: two identify the parties, five bound what the agent may do ^[10]. A merchant validating that object is comparing a proposed charge against a policy. The comparison has to run after the total is final, which is where the $1,900 attempt fails ^[7].

The three protocols named in the announcement answer different questions. Visa's Trusted Agent Protocol is designed to help merchants verify AI agents and establish the context of their requests ^[3]. Mastercard's Verifiable Intent focuses on verifying that an agent's action corresponds to an instruction the user authorized ^[4]. Ant International's Agentic Mobile Protocol covers transactions involving digital wallets ^[5]. Mapped onto the post's four layers, that is one piece of identity, one piece of intent, and one execution path.

Before a merchant can decline an over-limit agent charge on evidence, three things have to be in place.

1. The user's grant has to travel with the request as something the merchant can verify without calling the user. 2. The grant has to be comparable against the final total at authorization time. 3. Expiry and revocation have to be checkable, or the 24-hour lifetime in the post's sketch is 24 hours of unchecked authority ^[9].

All three need an agreed representation of the grant, and the post does not report a timeline for one.

In my context, building something that spends a user's money, the layer to implement first is the grant. A signed ceiling with a category and a merchant list is useful to my own risk checks whether or not a network ever asks for it. The post describes the KYA initiative as an effort to make different agent ecosystems work together ^[18].