The Pain: For the past six months almost every Agent conversation has been about whether it will do the wrong thing. Last month Meta let a consumer agent book trips and pay on its own; the payment networks immediately asked a question that sits one step earlier — why should anyone believe that this payment comes from an authorized agent rather than a hijacked script? Money can already move. "Who is moving it" still has no agreed answer across the industry.
What You'll Learn: A deployment-ready method for making an agent prove its identity — why payment networks solve identity before quota; what the freshly announced Know-Your-Agent framework actually promises and where it still falls short; and the three-part authorization trail you can add to your own system tonight, without waiting for a single new standard. All backed by real fields and real thresholds.
Last time I wrote about Meta handing a consumer agent the pay button, and I closed on one line: hand anything that can be made deterministic to code, and box whatever must be left to the LLM with a quota. Today I move the gate one step earlier — quota answers "how much it may spend", but it cannot answer "who is spending".
1. The payment networks ask about identity first, not quota
On September 9 and 10, Ant International, Visa and Mastercard announced that they will work together on a Know-Your-Agent (KYA) interoperability framework. The official BusinessWire release is carefully worded: the framework is meant to help card networks, digital wallets, agent platforms and marketplaces line up how an agent is onboarded and recognized, so AI-driven payments become safer and can scale. PYMNTS, Forkast and The Next Web all picked it up.
Notice the order. For the past two years, when we added guardrails to an agent, the first reflex was "how much quota does it get" and "which tools can it call". Now the payment networks have moved the first question to: who is this agent, on whose behalf is it acting, how wide is its mandate, and is it still inside that mandate right now.
Quota is an arithmetic problem; identity is a proof problem. Get the arithmetic wrong and the bill shows it. Get the proof wrong and a mis-payment in fully compliant clothing can walk the whole process end to end.
KYA is positioned as the mirror image of KYC: KYC verifies the person opening the account, KYA verifies the machine acting for them. The difference is that a person has one identity, while an agent's identity is a combination of principal, mandate scope and validity period — and it has to be verifiable by a third party across networks. That is exactly why a token issued by one platform is not enough on its own.
2. A framework with no spec, no governance, no timeline
Enthusiasm is fine, but you need to see where this actually stands today.
Forkast's coverage delivered three "nos": the framework is currently a high-level interoperability intent — no specification, no governance mechanism, no timeline. Three competing payment protocols have promised to interoperate; the technical details and the governance rules are not there yet.
That is not a criticism. This is how standardization usually goes — an intent statement first, then a draft spec, then implementations and certification. But for anyone actually putting an agent to work it means something very practical: on identity, you cannot wait for the standard to grow before you act.
On the same timeline, Google's Agent Payments Protocol does a different job — it records what each party saw at the moment of a transaction, which helps with after-the-fact reconciliation. Fortune's coverage pointed at the gap, though: when an agent buys something you never approved, that record does not help you. A record is not an authorization; a log entry showing the event does not mean the event was ever permitted.
3. Make "who approved this" a required answer for every action
What we do on our side is plainer than a framework, and much older.
This system has been running for 276 days, and the error ledger holds 80 incidents, each written out in four parts: symptom, root cause, fix, status. It has always answered "what went wrong". This KYA news made me realize the ledger is missing a field — approved_by, answering "who authorized this". An incident ledger serves postmortems; an authorization ledger serves accountability. Two different jobs.
Around that field we already have three things running.
First, policy-first. Every action goes through ALLOW / DENY / escalate-to-human before it runs, with rules written in code rather than in a prompt. That is our gate zero — it sits at the very top of the push script and calls exit if it fails, so there is physically no way around it.
Second, scope checking. After the agent declares who it is and on whose behalf it acts, the system checks whether this particular action falls inside the mandate it was granted. Scope is a list, not a feeling — tools run on an allowlist, and credentials never enter the agent's environment.
Third — the action trail, append-only. On that line we are still missing approved_by, which is the piece this post is about adding.
One thing to watch: mandate drift. An action allowed today may no longer be the same action three months from now. A mandate is not permanently valid just because it was granted once — that is the second thing the trail has to watch.
4. A copyable authorization skeleton
In code, an authorization check is as plain as a quota gate. The core idea is to split "what it wants to do" and "what it is allowed to do" into two things that must each pass separately.
# Authorization check: prove who, before letting it act
def authorize(agent, action):
if not agent.identity: # who is acting
raise Denied("no identity") # anonymous -> reject
if action.tool not in agent.allowed_tools: # what it may do
return escalate_to_human(action) # out of scope -> human
if not agent.mandates.matches(action): # on whose behalf
raise Denied("out of mandate") # beyond mandate -> reject
if action.amount > agent.confirm_threshold:
return escalate_to_human(action) # big action -> human
rec = execute(action) # only place it acts
ledger.append(rec, actor=agent.identity, approved_by=action.approval)
return rec
The way to verify it is the same as verifying a publishing gate — three steps and you can watch the authorization chain do its job:
# dry-run the three boundaries
python3 authz.py --dry-run --anonymous # expect: Denied: no identity
python3 authz.py --dry-run --tool unknown # expect: escalate_to_human
tail -3 ledger.jsonl # expect: every rec has approved_by
The order still cannot be reversed: identity and scope first, then the ability to act. Let the agent run first and patch authorization later, and you have signed your name to a blank cheque.
5. Trail first, standard later
Frameworks like KYA will eventually solve "verifiable" — letting an agent's identity be recognized by a network it has never met. They cannot solve "should it". A beautiful credential still does not tell you whether this payment makes business sense.
So the honest answer for now is to run two tracks in parallel: wait for the standard on one side, and make your own authorization trail solid on the other. The standard is somebody else's timetable; the trail is yours. On the day the standard lands, an action ledger with complete fields is the first thing you hold that can be aligned with it directly.
The boundary has to be stated just as clearly. This setup answers "who authorized it, how wide was the scope, was it ever exceeded". It does not answer whether the authorization itself was a good idea. The first is an engineering problem; the second is still a human call.
Identity is not a certificate; it is being able to answer "who approved this" for every single action.
Closing
Payment networks starting to ask "who is this agent" means the road has reached the depth where identity infrastructure is required. For those of us building, that is good news — because the trail is the one part that does not depend on anyone's spec landing first.
Machines handle speed, humans handle correctness. One addition: the ledger handles answering who let it be fast.
One-liner: three payment networks just agreed to work on Know-Your-Agent, giving agents an identity verifiable across networks — but the spec has to wait, while "who approved this" can ship tonight, so build the authorization trail before you build the credential.
📖 Further reading from the Practitioner's series
- Meta Gave an Agent the Pay Button: Four Money Gates You Need Before You Let It Spend
- The Kill Switch Bill Cannot Stop Runaway Agents — Physical Brakes Are the Last Mile of Agent Governance
- Orphan Code in Your Enterprise Network — An Engineering Answer to Coding Agent Supply Chain Security
About the author: Wu Ji (无记) — AI & digitalization practitioner focused on Agent engineering, Loop Engineering, and digital transformation. Practical, hands-on tutorials — follow along and it just works.
Top comments (0)