Delegated identity stacks turn agent authentication and payments into KYA evidence
The July 28 KYA signal is that AI-agent identity is splitting into layers: the person, the agent, the delegated authority, the credential, the tool call, and the payment. That separation is exactly what a Know Your Agent control file has to prove before an AI agent can authenticate, act, and pay on behalf of a user or business.
Daily signal: Discord tech-intel channel 1468032405695627386 was readable for the last 24 hours and surfaced general AI/product/security items, including AI lobbying and a Wero payment integration item, but no direct KYA finance topic was strong enough on its own. Web fallback and source verification were used. This is an identity, security, protocol, and payment-infrastructure signal, not formal Know Your Agent adoption by a regulator, exchange, bank, or payment scheme.
Why this matters for KYA
Biometric Update's July 28 coverage framed a delegated identity stack around three developments: 1Password's credential delegation for Claude, Dai Nippon Printing's agentic-commerce identity management using verifiable credentials, and the Linux Foundation governed x402 payment protocol. The shared theme is simple: an AI agent should not become the user, but it needs proof that it is authorized to act for the user.
1Password's model keeps credentials outside the model and memory, asks the user which credential is being requested and why, injects the secret at runtime after user approval, and scopes access to the current task. DNP's CATRINA-based approach focuses on proving whose proxy the AI agent is and with what authority it can make purchases. x402 addresses the payment layer, where agents, APIs, and applications can send or receive payments through an open HTTP payment standard.
For APAC finance, this turns KYA from a single "agent identity" label into an evidence architecture. If an agent can log in, request a one-time code, perform an online purchase, invoke payment APIs, or call MCP tools, the operator needs a record that separates credential access from delegated authority and separates delegated authority from transaction execution.
Screenshot-ready KYA compliance comparison table
| KYA dimension | Weak delegated-agent posture | KYA-ready delegated identity posture | Evidence reviewers should expect |
|---|---|---|---|
| Operator identity | The AI agent acts through the user's account and appears as the user in logs. | The person, business, agent, credential broker, payment protocol, and tool client are separately identifiable. | User or business account, agent ID, agent owner, credential broker, payment client, tool client, activation and revocation status. |
| Agent mandate | The agent receives broad account access once a login succeeds. | The mandate states the exact task, allowed account, action type, spend or data limit, approval requirement, and expiry. | Task record, permitted actions, user consent event, reason shown to user, expiry, denied actions, escalation path. |
| Wallet and custody | Payment capability is inferred from the authenticated account or stored credential. | The payment credential, wallet, rail, amount, recipient, token or currency, and settlement path are checked against delegated authority. | Credential-use receipt, x402 payment proof, wallet or rail authority, amount, recipient, settlement reference, refund or dispute route. |
| Tool and venue access | The same authenticated browser or agent session can use many sites, tools, and APIs. | Every tool or venue call is scoped to method, resource, schema, user mandate, authorization context, and policy decision. | MCP method and tool name, input and output schema validation, OAuth or OIDC issuer, allowed resource, blocked-call log. |
| Audit trail | The record shows a completed login or purchase but not the agent's delegated chain of action. | The record links user approval, credential request, credential injection, tool call, payment instruction, execution, and result. | Request ID, consent timestamp, credential-use event, tool-call trace, payment proof, final outcome, reviewer note. |
| Security and abuse | Controls focus on password protection and fraud after the transaction. | Controls detect prompt injection, credential overreach, mandate drift, malicious tool output, beneficiary changes, and payment abuse before execution. | Secret-exposure check, prompt-risk result, policy denial, anomaly score, beneficiary-change alert, kill-switch or revocation event. |
| Jurisdiction fit | Delegated agent actions are treated as ordinary ecommerce or SaaS automation. | The agent workflow is mapped to payments, privacy, outsourcing, consumer protection, AML, sanctions, e-signature, and dispute rules by market. | Jurisdiction matrix, payment-license basis, privacy basis, retention policy, screening evidence, local dispute route, vendor assessment. |
The compliance lesson
The key control lesson is that credential delegation is not the same as financial authorization. A user can allow an agent to use a login without authorizing every action behind that login. A business can let an agent prepare a purchase without letting it execute a payment. A protocol can prove a payment without proving the agent was allowed to initiate it.
KYA needs to bind those layers together without collapsing them. KYC identifies the user. KYB identifies the business. KYA identifies the delegated software actor and proves what it was allowed to do at a specific point in time. That proof becomes especially important when an agent moves across browser tasks, credential brokers, MCP servers, payment protocols, and ecommerce or finance venues.
The MCP 2026-07-28 release-candidate signal reinforces the same pattern for tool calls. Stateless requests, request metadata, method headers, trace context, JSON Schema contracts, and OAuth/OIDC hardening all make it easier to ask the KYA question at the gateway: which agent is calling which tool, on behalf of which user, under which authority, and with what result?
Practical KYA checklist
- Record the user, business, agent, credential broker, tool client, and payment client as separate actors.
- Show the user or business what credential, account, action, recipient, amount, and reason the agent is requesting.
- Scope credential use to the current task and verify that the model never receives the secret or one-time code.
- Require payment-specific evidence for wallet or rail authority, recipient, amount, token or currency, payment proof, and settlement result.
- Validate MCP or API tool calls at the edge using identity context, method, schema, resource scope, and policy decision.
- State the caveat clearly: delegated identity and x402 are infrastructure signals, not enacted KYA rules or formal regulatory endorsements.
Bottom line
Delegated identity stacks are making the core KYA problem visible. The agent should be able to act for a user, but it should not become the user. The compliance file has to prove identity, authority, credential handling, tool access, payment execution, audit trail, abuse controls, and local jurisdiction fit before autonomous action is treated as authorized.
Sources reviewed: Discord tech-intel channel 1468032405695627386 for the last 24 hours; Biometric Update coverage of 1Password, DNP, and x402 delegated identity signals; Model Context Protocol 2026-07-28 release candidate; Agentic AI Foundation MCP platform-governance analysis; Finder / Stacker agentic trading coverage. These are industry, product, security, protocol, and market-structure signals, not enacted KYA rules.