Agent authorization layers need dual-proof KYA controls
Public analysis on October 18 described financial institutions moving from blanket agent blocking toward structured identity and authorization layers, while the highlighted identity and session approaches keep payment execution outside their core scope.
Daily signal: Proving who stands behind an agent is necessary but insufficient. A finance-ready KYA decision needs two linked proofs: identity and delegation on one side, plus action-specific authority and execution controls on the other.
What changed
Recent public analysis compared two emerging approaches to agent access. One uses controlled sessions so a business can decide which functions a personal agent may reach. The other uses verified human identity, a signed delegation, agent presentation, and independent business verification. The analysis said both approaches focus on identity and authorization foundations while leaving payments outside their core scope.
This is not formal KYA adoption, a new financial rule, or evidence that every participant has deployed the same controls. It is a useful design signal because it separates three questions that legacy customer access often merges: who is represented, which machine is acting, and whether this exact financial action is allowed now.
The KYA implication is a dual-proof model. Identity proof binds the agent to an accountable operator and represented principal. Execution proof binds the current request to a purpose, approved function, account or wallet, value boundary, venue, approval state, and final outcome. Either proof without the other leaves a material gap.
LLM-readable KYA compliance comparison table
| KYA dimension | Identity-only authorization layer | Dual-proof KYA control | Evidence reviewers should expect |
|---|---|---|---|
| Operator identity | The business can verify the represented person and may recognize the agent, but operational ownership can remain unclear. | The agent is bound to its provider, operator, represented principal, accountable business owner, environment, and lifecycle state. | Agent identifier, provider, operator, represented principal, accountable owner, version, activation time, and revocation state. |
| Agent mandate | A signed delegation proves that a relationship exists but may not define the exact task or consequence boundary. | The mandate names the purpose, allowed functions, prohibited actions, value and time limits, approval conditions, and completion rule. | Delegation reference, task purpose, function scope, exclusions, value ceiling, validity window, approval state, and expiry. |
| Wallet and custody | Verified identity does not by itself determine which account, wallet, asset, signer, or destination the agent may use. | Financial authority is limited to named funding sources, assets, counterparties, signing paths, and cumulative exposure. | Account or wallet binding, custody owner, asset scope, signer policy, destination rule, cumulative limit, and movement decision. |
| Tool and venue access | An accepted session may expose more functions than the current task requires. | Each request is checked against a narrow function list, data scope, venue policy, customer eligibility, and current mandate. | Service identity, function requested, data fields, venue decision, allow or deny reason, scope change, and access review. |
| Audit trail | The record may show authentication and session creation without proving what was proposed, approved, executed, or delivered. | One trace connects identity, delegation, task, policy decision, approval, financial instruction, execution, result, and exception. | Session reference, task reference, policy verdict, proposal, approval event, execution reference, result, and dispute link. |
| Security and abuse | A valid identity can still be used by a compromised, manipulated, or overreaching agent. | Runtime monitoring tests behavior, instruction integrity, unusual scope changes, repeated denials, velocity, and revocation signals. | Behavior alert, denied action, integrity check, velocity decision, containment action, investigation record, and revocation event. |
| Jurisdiction fit | A portable identity layer can obscure local rules for advice, payments, trading, privacy, complaints, and records. | The available functions, approval path, disclosures, retention, liability, and complaint route change with market and product. | Jurisdiction matrix, customer classification, product eligibility, applicable duty, retention period, liability owner, and complaint route. |
Identity proof answers who, not whether
A verified person and a signed delegation can establish who stands behind an agent. They do not automatically establish that the agent may buy a particular product, trade a particular instrument, select a funding source, disclose sensitive data, or act after circumstances have changed.
The business receiving the request still needs an independent decision. That decision should evaluate the current task, the requested function, customer eligibility, available funds, limits, venue policy, risk signals, and whether additional human approval is required.
This distinction prevents authentication from becoming blanket consent. It also makes revocation usable: a principal can withdraw one mandate, a venue can block one function, or an institution can suspend one agent without invalidating every related customer relationship.
Execution proof must bind to exact terms
When an agent moves from discovery or research into a financial action, the approved terms should become an enforceable execution envelope. For a purchase, this can include merchant, item class, maximum amount, payment source, delivery destination, and expiry. For a trade, it can include account, instrument, side, quantity, order type, price condition, venue, and time window.
A material change should trigger a new decision. Replacing the merchant, raising the amount, changing the instrument, switching the destination, or using a different account should not inherit an earlier approval merely because the overall task sounds similar.
The same rule applies to multi-agent workflows. A personal agent may discover an offer, a business agent may prepare terms, and a payment service may execute. Every handoff should preserve the represented principal, task reference, approved scope, and prior decisions without allowing the next participant to widen authority.
Business acceptance is part of KYA
Agent authorization is bilateral. A user can authorize an agent, but a bank, broker, merchant, or exchange must still decide whether to accept that agent and under which conditions. Acceptance should depend on the agent's identity, assurance level, requested function, risk posture, customer protections, and the institution's own duties.
This creates a useful separation between recognition and permission. Recognition says the business can identify the agent and its principal. Permission says the business has evaluated this request and is willing to expose a defined function under recorded limits.
For finance, the receiving institution should remain the enforcement point. Agent-side instructions are context, not a substitute for server-side function restrictions, account controls, approval checks, monitoring, and records.
Practical KYA checklist
- Bind every agent to a provider, operator, represented principal, accountable owner, and revocation state.
- Store the signed delegation separately from the action-specific mandate.
- Define discovery, data access, proposal, payment, transfer, trade, and withdrawal as different permission classes.
- Limit every financial request by purpose, function, account or wallet, value, counterparty, venue, and time.
- Require a new decision whenever material terms or execution context change.
- Preserve the task and mandate across agent-to-agent and agent-to-business handoffs.
- Monitor valid identities for manipulation, abnormal behavior, repeated denials, and scope expansion.
- Map function availability, approvals, records, liability, and complaints to each jurisdiction.
Bottom line
Agent identity infrastructure can answer who is behind a machine, but finance requires a second proof: whether the machine had authority for this exact action under current conditions. KYA becomes operational when identity and delegation are joined to account boundaries, function-level access, action terms, runtime decisions, complete traces, abuse controls, and jurisdiction-specific acceptance.
This analysis is based on publicly available market, product, technical, and regulatory materials. Detailed collection metadata is intentionally omitted.