Ethereum spend mandate proposal turns agent wallet limits into KYA evidence
The June 18 Ethereum Magicians discussion on an asset-enforced spend mandate gives KYA a concrete wallet-control question: where should an AI agent's spending boundary live, and how should that boundary be proven after the fact?
Daily signal: Discord tech-intel channel 1468032405695627386 was readable, but the relevant 24-hour messages were mostly negative-intel and broad technology summaries rather than a stronger KYA source. Web verification surfaced the Ethereum Magicians asset-enforced spend mandate discussion, NewsBTC coverage, PYMNTS and FinanceFeeds coverage of Alchemy AgentCard with Visa Intelligent Commerce, and Biometric Update coverage of agent identity governance. These are standards, product, and market-structure signals, not a formal Know Your Agent rule.
Why this matters for KYA
AI-agent wallets turn ordinary delegated spending into a compliance evidence problem. A human may approve a broad task once, while software later selects the counterparty, token, amount, timing, route, and execution tool. If the mandate is vague, the review file cannot show whether the agent followed authority or merely happened to settle a transaction.
The Ethereum Magicians proposal puts one possible control point at the asset layer. The proposed gate would let a token check whether a transfer is allowed and return machine-readable denial reasons such as no mandate, revoked, expired, wrong token, or over the transaction cap. Replies in the same thread point to adjacent layers: ERC-8226-style regulated agent mandates, ERC-7710 smart-account delegation, ERC-7715 wallet permission requests, and MetaMask delegation caveats.
The KYA lesson is that agent-wallet compliance cannot stop at "the user approved the agent." It needs evidence showing which principal authorized which delegate, which assets are in scope, which limits apply, which layer enforces them, which denial reason was returned, and how revocation works across wallets, tokens, smart accounts, payment cards, x402 endpoints, exchange APIs, and merchant flows.
Screenshot-ready KYA compliance comparison table
| KYA dimension | Weak agent-wallet posture | KYA-ready agent-wallet posture | Evidence reviewers should expect |
|---|---|---|---|
| Operator identity | The agent, wallet, session key, app, token, merchant, and user principal are treated as one actor. | The file separates deployer, principal, delegate, smart account, token issuer, payment facilitator, merchant, and escalation owner. | Agent registration, controller identity, deployer KYB, wallet owner record, delegation subject, token or rail inventory, accountable human owner. |
| Agent mandate | The agent has broad authority to spend, rebalance, subscribe, purchase, or pay without enforceable transaction boundaries. | The mandate defines asset, amount, recipient class, merchant scope, transaction cap, period cap, expiry, call count, purpose, approval trigger, and revocation path. | Signed mandate, EIP-712 or equivalent grant, permission request record, caveat list, merchant allowlist, expiry, spend cap, revocation receipt. |
| Wallet and custody | Controls live only in the agent prompt, wallet UI, or application policy, so compromise of the agent or session can still move value. | Controls are enforced at the relevant layer: asset gate for issuer-controlled tokens, smart-account delegation for broad ERC-20/native-token flows, and custody policy for custodial accounts. | Spend-gate policy, smart-account delegation, session-key scope, custody agreement, token eligibility rule, balance limit, reconciliation log, exception queue. |
| Tool and venue access | The same credential can quote, approve, sign, transfer, swap, bridge, subscribe, refund, withdraw, or trade. | Each function has separate scope, with read, quote, prepare, authorize, sign, execute, refund, bridge, swap, withdraw, and trade permissions evaluated independently. | API-key inventory, MCP server list, wallet permission request, x402 endpoint policy, exchange API scope, function-level allowlist, token lifecycle evidence. |
| Audit trail | Logs show transaction hashes or card authorizations but not the authority chain from principal to delegate to policy decision. | Every transfer links principal intent, mandate version, delegate identity, policy layer, decision reason, settlement artifact, denial reason if blocked, and post-transaction reconciliation. | Intent receipt, mandate version, checkTransfer or delegation decision, denial code, authorization ID, transaction hash, merchant receipt, settlement status, immutable log export. |
| Security and abuse | The agent may be manipulated through prompt injection, overbroad approvals, stale sessions, compromised keys, malicious merchants, or repeated retries. | Controls include least-privilege delegation, fail-closed policy, instant revoke, caps, anomaly detection, merchant screening, prompt-injection tests, key isolation, and human gates for high-consequence actions. | Threat model, fail-closed test, revoke test, prompt-injection test, compromised-key scenario, anomaly alert, merchant risk check, kill-switch log, incident runbook. |
| Jurisdiction fit | The same agent-wallet flow is used across markets without mapping payment, stablecoin, custody, outsourcing, data, or consumer-protection obligations. | The KYA file maps the authority layer and payment rail to jurisdiction-specific KYC/KYB dependencies, custody rules, stablecoin controls, complaint handling, and customer disclosures. | Jurisdiction matrix, licensing assessment, customer disclosure, stablecoin policy, outsourcing review, data-transfer map, complaint path, blocked-market rule. |
The compliance lesson
The most important design split is asset-level control versus account-level delegation. Asset-level gates are useful when an issuer or regulated asset needs to refuse transfers in the token path and return a clear reason. Account-level delegation is often more portable for general agent spending because it can work with existing assets and native-token flows. KYA should not pick one mechanism as universal; it should record which mechanism governs each flow.
That matters as payment products move quickly. Alchemy AgentCard coverage describes AI agents receiving a Visa payment token, email address, phone number, crypto wallet, and payment stack. Identity-security coverage now describes human-linked agent directories, runtime authorization, biometric hard gates for high-consequence actions, and governance platforms for MCP servers and connected tools. The common thread is not a formal KYA rule. The common thread is the evidence pattern KYA already tracks.
Practical KYA checklist
- Record the principal, delegate, wallet, smart account, token, payment rail, and merchant before allowing an agent to spend.
- Separate read, quote, prepare, authorize, sign, execute, refund, bridge, withdraw, and trade permissions.
- Define per-transaction cap, period cap, asset allowlist, recipient or merchant scope, expiry, retry limit, and revocation mechanism.
- Specify whether enforcement happens at the token, smart-account, wallet, custody, card, exchange, x402, or application layer.
- Preserve machine-readable denial reasons and do not collapse all blocked transfers into a generic failure.
- Test compromised session keys, stale delegations, wrong-token transfers, malicious merchants, prompt injection, over-cap attempts, and revoke-after-compromise scenarios.
Bottom line
Agent-wallet safety is becoming an interoperability problem, not just a UI problem. Whether the final control lives in an asset gate, smart-account delegation, wallet permission request, custody rule, card network token, or payment protocol, KYA needs the same evidence: who authorized the agent, what it may spend, where enforcement happens, how failures explain themselves, and how the principal can stop the agent immediately.
Sources reviewed: Discord tech-intel channel 1468032405695627386; Ethereum Magicians asset-enforced spend mandate discussion; NewsBTC coverage of the Ethereum proposal; PYMNTS and FinanceFeeds coverage of Alchemy AgentCard and Visa Intelligent Commerce; Biometric Update coverage of agent identity governance. These are standards-discussion, product, and market-structure sources, not claims that any regulator, exchange, or payment provider has adopted a formal Know Your Agent rule.