On September 10, Ant International, Visa and Mastercard announced they will work toward common principles across their three agent identity protocols, under BuildFin.ai, the industry platform convened by the Monetary Authority of Singapore. The press release names three goals: cross-network operator traceability linking each agent to a validated operator, cardholder or business; shared certification requirements covering security and behavioral standards; and continuous transaction monitoring. It gives no specification and no date. Ant's chief innovation officer Jiang-Ming Yang put the practical aim in one sentence to Forkast: "If an agent registers with Ant, they don't need to register again with Visa, Mastercard."
Register once. That makes Know-Your-Agent a directory problem, and it is worth being precise about what a directory can say about an agent and what it cannot.
The three protocols already agree on the signature. They disagree on the directory.
Visa's Trusted Agent Protocol, launched with Cloudflare in October 2025, signs the agent's HTTP request with RFC 9421 message signatures. The Signature-Input header carries a keyid, timestamps inside an eight-minute window, a nonce, and a tag that is either agent-browser-auth or agent-payer-auth. The merchant fetches the key named by keyid and checks an Ed25519 signature. Cloudflare's engineering writeup says where that key comes from: "Visa and Mastercard will be hosting their own directories for Visa-registered and Mastercard-registered agents, respectively."
Mastercard's Verifiable Intent, published with Google in March 2026, works one layer up. Its specification is a chain of SD-JWT mandates from credential provider to user to agent, each layer bound to the next by an RFC 7800 confirmation claim, and in autonomous mode the mandate's cnf.jwk is the agent's key. The README lists "key management/provisioning" and "credential provider enrollment" as out of scope. The chain proves the agent acted inside what the user delegated, not how anyone learns which agent keys exist.
Ant's Agentic Mobile Protocol, open-sourced in April, is the only one of the three whose materials describe rating an agent. Its launch release describes a KYA framework that "establishes an agent's digital identity and certifies its authorised capabilities" and a proprietary Agent Trust Rating that "determines whether an agent is trustworthy and controls the level of autonomy."
So the primitive is settled: the agent holds a private key and the relying party checks a signature. What is not settled is who runs the directory, and whether the directory may say more than "this key is ours". This week's announcement defers both.
What our registry signs
We run the same shape of problem at Pilot Protocol, for traffic between agents rather than between an agent and a merchant.
The daemon generates its own Ed25519 identity. The startup path in pkg/daemon/daemon.go loads a persisted identity from the configured path and, if none exists, generates one and saves it. Registration sends the base64 public key with a signature over the registration message; the private key is not a field in that message. The registry assigns the 48-bit virtual address and records network membership.
Any web service, on or off the network, can then ask the registry three questions about a request and get a signed answer. The mechanism is written up in SIGNATURE-VERIFICATION.md in the main repo. A node signs a canonical envelope containing its address, a timestamp, a nonce, the SHA-256 of the request body, and an audience string naming the one service the signature is for. The service posts envelope and signature to /api/v1/verify on the registry dashboard and gets back:
-
valid: the signature verifies against the registered, unexpired key for that address. A random Ed25519 key fails structurally, because no address is bound to it. -
online: the node's last signature-verified heartbeat is within 180 seconds. The document is careful to call this standing, not reachability. -
network_member: the node belongs to the network in the address prefix.
The response also carries a pilot-verdict-v1 string signed by the registry's issuer key, so the service can cache it, forward it as proof, or check it offline. The issuer key is published at /api/v1/verify/keys, and the production endpoint returns one Ed25519 key under kid vfy-v1 at the time of writing. Failures are uniform: unknown node, reaped node, bad signature, stale timestamp and expired key all return the same {"valid": false}, so the endpoint cannot be used to enumerate the address space. Nodes silent for longer than thirty minutes by default are reaped and stop verifying until they re-register.
That is what continuous monitoring means at the identity layer for us: liveness and membership, signed, failing closed.
Operator traceability without naming the operator
KYA's first goal is linking each agent to a validated operator. Our version is the verified-address badge, defined in the badgeverify package of our common module. A badge is a detached Ed25519-signed credential bound to a single node ID, verified offline against a pinned issuer key, asserting that the address was verified through GitHub, Google or WorkOS. The package comment says it "deliberately carries NO raw external identity": no GitHub login, no email, only which provider vouched and when. The issuer's private key lives in Cloud KMS, and address recovery is signed by a separate cold keyring, so compromising the badge issuer cannot seize an address. pilotctl verify --provider github runs the device flow end to end.
That is a deliberate narrowing of traceability. A peer learns that a real account at a real provider stood behind this address when the badge was issued. It does not learn whose.
The decision the directory refuses to make
A merchant running Visa's protocol verifies a signature against Visa's directory and decides alone whether to serve the request. Between agents there is no merchant. So our IETF draft makes trust bilateral. Section 10.6: two agents exchange trust requests on virtual port 444 with justification strings, and both must approve. Auto-approval happens only when both independently requested each other, or when both share a non-backbone network; otherwise the request queues for the receiving agent's operator. Nodes are private by default (section 10.7): the registry will not resolve a private node's endpoint without a mutual trust pair or a shared non-backbone network.
The registry records the trust pair. It does not make it. The daemon does have a --trust-auto-approve flag, and the enterprise security profile in cmd/daemon/security_profile.go refuses to start with it set.
What we do not do
We do not certify behavior. The signed verdict says registered, alive and member; the badge says a provider vouched; the trust pair says a peer consented. None of that is a rating. KYA's second pillar, shared certification of "security and behavioral standards", is also the part none of the three payment protocols has published a mechanism for.
The other thing worth saying plainly is in section 19.5 of our draft: the registry is a centralized trusted third party, and its compromise could allow public key substitution. Our mitigations are TLS with optional pinning, signature verification on node operations, hot-standby replication and audit logging, with distributed registry designs listed as future work. A shared KYA directory inherits the same single point, across three networks and the ten wallets in AMP's first phase. Register once is the right goal. It should come with a written statement of what the directory asserts about an agent, and what it does not.
Top comments (0)