Agent Identity & Know-Your-Agent (KYA)

KYA answers who the agent is and which operator/principal it is attributed to. Spend policy answers how much it may pay (cap, clock, revoke). Harness permission answers which connectors and network egress the host grants. Do not collapse those three planes. A payment capability is not an identity document; an egress allowlist is not KYA. See /playbooks/agent-payments-spend-policy/ and /playbooks/harness-permission-outside-agent/.

The collaboration announcement names protocols already rolled out: Visa Trusted Agent Protocol, Mastercard Verifiable Intent, and Ant International Agentic Mobile Protocol. Record which rail your agent actually hits today. Do not invent a fourth “IZHC KYA cert.” Do not quote executives. The work now is exploring common principles across those protocols, not replacing them.

As of the 2026-09-10 announcement, the three organizations have begun collaboration on a KYA interoperability framework: shared principles, while each network preserves its own verification and decisioning. BuildFin.ai (MAS-convened) and the SAFR framework are named as the Singapore collaboration venue. There is no public technical spec, governance body, or rollout date in the announcement. Do not block launch on a finished shared cert that does not exist. Do not treat unsigned press as a live standard.

The announcement centers KYA collaboration on: (1) cross-network operator traceability — each agent linked to a validated operator, cardholder, or business/organization; (2) shared certification requirements — security and behavioral assessment so the agent operates as expected; (3) continuous transaction monitoring — identity plus transaction signals for ongoing assessment. Use these as operator design themes. Implement what your current rail actually supports; do not invent a shared certification API.

LangChain Connections (Managed Deep Agents) stores named credentials in the LangSmith workspace. Owner is independent of credential type: agent-owned (shared by every caller; service-account path) vs caller/user-owned (resolved per person at runtime; on-behalf-of path). Ownership is fixed at create (`mda connections create`) and does not change later. `connections.get()` pauses for an OAuth grant when the caller has none. Match the identity you want on the ticket/charge (bot vs person) to the connection owner. See /resources/tools/langchain-managed-deep-agents/.

Until networks publish interoperable verification you can actually present, keep your own operator attribution, Connections ownership, and rail-specific protocol. The McKinsey US$3–5T-by-2030 figure in the announcement is a cited projection of agent-orchestrated consumer commerce — not an Institute TAM and not a reason to skip identity. Revoke Connections and spend mandates on a separate clock from identity records.

Agent and machine-to-machine credentials are the blast radius. WorkOS (2 Oct 2026) summarizes Microsoft Security Research (25 Sep) on Storm-3168 (Sysdig’s JADEPUFFER actor): two compromised Azure service principals enumerated a tenant for more than 15 hours, then deleted most of 100+ storage accounts plus a Key Vault, Function App, and App Service plan in about 7 minutes. No Azure CVE — the roles were already assigned. Likely entry: a client secret posted in a public GitHub issue, later edited out but still valid in edit history. Resource locks / deletion protection blocked some deletes; SQL deletes failed on an unsupported API version. Operator constraints: edit is not revoke — rotate any publicly exposed secret; prefer managed identity or federation over long-lived client secrets; narrow Contributor and delete roles; put CanNotDelete locks on critical resources; alert on unusual workload-identity reads; keep dual-active secrets so rotation is routine. Pair with spend-policy principals on /playbooks/agent-payments-spend-policy/.