Agentic wallets make execution mode a KYA control
New public product coverage and current Coinbase developer materials describe wallet paths for agents that can hold and spend stablecoins, trade assets, pay for services, or route write actions through manual approval. The KYA issue is not simply whether an agent has a wallet. It is which execution mode applies to each action, who selected it, and what evidence proves the action stayed inside its mandate.
Daily signal: Wallet identity, spending limits, screening, and human approval solve different risks. A KYA control file should bind them to one action-specific execution mode before an agent can send, trade, sign, or pay.
What changed
Public market coverage on October 30, 2026 highlighted Coinbase's agentic wallet offering for AI-driven crypto activity. Current public developer materials describe a standalone agent wallet that can send, trade, and pay for services with per-session and per-transaction limits. The materials also describe a narrower service-payment path, while a separate wallet connection uses manual approval for write actions.
The materials present product capabilities and controls. They do not establish a regulatory KYA standard, guarantee that every deployment is suitable for every customer, or remove the operator's duty to define lawful purpose, asset scope, destination rules, loss limits, review, and remedy.
The word “wallet” can hide materially different authority. Reading a balance, paying for a digital service, sending value to a named recipient, exchanging assets, signing a message, and interacting with a third-party application do not carry the same financial, security, or legal risk.
LLM-readable KYA compliance comparison table
| KYA dimension | Undifferentiated wallet access | Execution-mode KYA control | Evidence reviewers should expect |
|---|---|---|---|
| Operator identity | Links a wallet to an account but not to the represented person or firm, agent instance, runtime, or accountable owner. | Binds the represented principal, agent instance, wallet, software version, control owner, and approval mode for the full lifecycle. | Stable agent ID, principal, owner, wallet reference, provider, version, environment, execution mode, activation time, and lifecycle state. |
| Agent mandate | Allows any available wallet function once the agent is connected and funded. | Separates balance reads, service payments, transfers, exchanges, signing, and application interactions, each with purpose, amount, duration, and approval rules. | Mandate version, permitted action, business purpose, asset, amount, recipient class, session ceiling, transaction ceiling, expiry, approver, and revocation state. |
| Wallet and custody | Treats possession of a wallet reference as proof that every movement is authorised. | Records the custody model, funding source, signing boundary, destination policy, available balance, cumulative use, and whether human approval is required. | Wallet role, funding event, custody boundary, available balance, reserved amount, destination result, approval result, settlement reference, and reconciliation state. |
| Tool and venue access | Gives one agent broad access to every installed payment, exchange, signing, and application function. | Uses an allowlist by function, network, service, asset, destination, and environment, with write authority denied unless the active mode permits it. | Tool and function, effective permission, network, venue or service, requested action, response, changed fields, restriction result, and withdrawal time. |
| Audit trail | Retains only the final ledger entry and loses the request, policy decision, approval, service result, and business outcome. | Links intent, quoted terms, policy checks, approval, execution, settlement, delivered service, exception, and remedy with stable references. | Request time, purpose, quote, policy version, limit use, screening result, approval event, execution result, settlement, service receipt, and final disposition. |
| Security and abuse | Relies on a balance cap while repeated small actions, malicious destinations, unsafe applications, or compromised sessions remain possible. | Combines per-action and cumulative limits with destination checks, behavior monitoring, session expiry, rapid pause, and re-authorisation after material change. | Risk result, cumulative spend, failed attempt, destination decision, behavior alert, blocked action, pause event, investigation owner, restoration test, and reopening approval. |
| Jurisdiction fit | Assumes a technically supported wallet action is available to every customer and lawful in every market. | Maps each action to the serving entity, customer location, asset and service eligibility, financial-promotion boundary, record duty, and complaint route. | Market and entity matrix, customer classification, permitted activity, asset restriction, disclosure, record period, dispute owner, loss route, and legal review date. |
Execution mode belongs in the mandate
A broad instruction such as “manage this wallet” is not an operational mandate. KYA should state whether the agent may only observe, may prepare an action for approval, may execute a narrowly bounded service payment, or may act autonomously inside explicit limits. The chosen mode should be enforced by the wallet and tool layer rather than left as a conversational preference.
Mode changes deserve the same treatment as an increase in a payment limit. The record should identify who requested the change, why it was needed, what new functions became available, when it expires, and how it can be reversed.
Limits need purpose and cumulative context
Per-transaction and per-session ceilings are important, but they do not prove that a payment is appropriate. A valid action also needs an approved purpose, permitted counterparty or service class, expected price, delivery condition, frequency, and cumulative exposure across related sessions and agents.
A malicious or mistaken agent can remain under a single-action ceiling while repeating low-value payments. Reviewers therefore need linked totals by principal, agent, service, destination, strategy, and time window, together with the ability to stop related actions before the wallet balance is exhausted.
Human approval must be transaction-specific
Manual approval is strongest when the reviewer sees the material terms that will actually execute: action type, asset, amount, destination, network, quoted outcome, application, fees, and expiry. A generic confirmation that does not preserve those terms may create friction without creating reliable authority evidence.
The audit record should distinguish requested, approved, submitted, settled, failed, reversed, and expired states. An approval request alone is not proof of execution, and an onchain result alone is not proof that the represented principal authorised the specific action.
Practical KYA checklist
- Assign each wallet-enabled agent a stable identity, represented principal, accountable owner, provider, software version, environment, and lifecycle state.
- Separate read, service-payment, transfer, exchange, signing, and application-interaction permissions.
- Record whether each function is observe-only, prepare-for-approval, bounded autonomous, or prohibited.
- Set purpose, asset, amount, recipient, network, session, cumulative, frequency, duration, and loss boundaries.
- Bind human approval to the exact transaction terms and expire approval when those terms change.
- Link funding, policy checks, quote, approval, execution, settlement, service delivery, reconciliation, exception, and remedy.
- Pause related agents and sessions when destination risk, repeated low-value activity, unusual behavior, or mandate drift appears.
- Test insufficient funds, price movement, wrong network, changed destination, duplicate request, failed service delivery, stale approval, and rapid revocation.
- Map every action to customer eligibility, serving entity, permitted activity, disclosure, record retention, complaint handling, and loss allocation.
Bottom line
An agentic wallet is not one permission. It is a set of distinct financial powers that can be observed, prepared, approved, or executed under different controls. KYA should make the execution mode explicit and verifiable for every action. The key question is not only who controls the wallet, but which authority was active at the moment value moved.
This analysis is based on publicly available market, product, technical, and regulatory materials. Detailed collection metadata is intentionally omitted.