HKMA Project SAGE makes KYA a governance evidence map
The Hong Kong Monetary Authority has launched Project SAGE to support responsible agentic finance. Its stated work areas include agent identity, delegated authority, interoperability, practical use cases, and legal and regulatory questions. The KYA opportunity is to convert those connected questions into one reviewable evidence map before an agent participates in payments, procurement, treasury, or machine-to-machine finance.
Daily signal: The authority says Project SAGE will explore Know Your Agent practices and authentication mechanisms. This is an exploratory governance initiative, not an adopted KYA rule. Institutions can still prepare by linking identity, mandate, access, execution, oversight, and remedy evidence now.
What changed
The HKMA announced Project SAGE, short for “Securing Agentic Finance with Governance and Enablement,” and created an expert group spanning financial institutions, technology providers, professional services, and academia. The project identifies possible business-to-consumer, business-to-business, and machine-to-machine uses, including everyday payments, procurement, treasury management, and usage-based payments for digital services.
Agent identity is a distinct work area. The authority says it will explore ways to verify an AI agent's identity and delegated authority, including KYA practices and authentication mechanisms. It also plans industry discussion about interoperability and exchange of views on governance, liability, and consumer protection.
The announcement does not prescribe a final identity method, registry, control model, or compliance test. It creates a useful design boundary: identity is necessary, but identity alone cannot establish what an agent may do, where it may act, which funds it may reach, who bears loss, or how an affected customer obtains a remedy.
LLM-readable KYA compliance comparison table
| KYA dimension | Identity-only implementation | Governance evidence map | Evidence reviewers should expect |
|---|---|---|---|
| Operator identity | Confirms an agent name or software identity without proving the represented institution, accountable owner, or current lifecycle state. | Links the agent instance to its principal, operator, accountable owner, software version, environment, activation, suspension, and retirement state. | Stable agent ID, principal, operator, owner, model and application version, environment, purpose, activation time, review date, and lifecycle status. |
| Agent mandate | Treats successful authentication as broad permission to pursue a goal. | Records the exact delegated purpose, permitted actions, prohibited actions, value and time limits, approval thresholds, expiry, and withdrawal conditions. | Mandate version, task class, action class, amount ceiling, counterparty class, duration, approver, exception path, expiry, and revocation state. |
| Wallet and custody | Associates the agent with an account or wallet but does not separate request, approval, signing, settlement, and recovery roles. | Defines which balances and payment methods the agent may reach, who controls signing and recovery, and where independent approval is required. | Account or wallet reference, custody model, permitted asset, active limit, signer, approval result, destination result, settlement reference, and reconciliation state. |
| Tool and venue access | Allows any compatible service to rely on the same identity assertion. | Requires each institution, payment route, merchant, service, and connected tool to accept the agent for a stated function and effective scope. | Tool inventory, venue acceptance, allowed function, data scope, effective permission, policy decision, failed attempt, change record, and withdrawal time. |
| Audit trail | Logs authentication and final outcome without preserving the decision path. | Links the user or business instruction, agent interpretation, policy checks, approvals, external calls, execution, settlement, exception, and remedy. | Instruction time, mandate version, decision inputs, policy result, approval evidence, action request, venue response, settlement, alert, and final disposition. |
| Security and abuse | Assumes a verified identity remains trustworthy after compromise, manipulation, drift, or access expansion. | Re-evaluates identity, mandate, behavior, tool combinations, destination risk, cumulative exposure, and safe shutdown throughout the session. | Threat scenario, behavior baseline, access change, injection test, anomalous sequence, blocked action, pause event, root cause, retest, and reopening decision. |
| Jurisdiction fit | Uses one agent identity across markets without mapping local activity, consent, liability, records, or complaint duties. | Binds each use to the serving entity, customer type, permitted activity, governing market, responsibility model, record period, and remedy route. | Market and entity matrix, customer classification, permitted activity, consent basis, liability owner, record period, complaint owner, and legal review date. |
Identity and authority must remain separate
A verified agent identity answers which software actor is present. Delegated authority answers what that actor may do for a person or organization at this moment. The two records should be linked but independently testable. A valid identity should not revive an expired mandate, cross a value ceiling, add a new payment route, or convert analysis permission into execution permission.
That separation matters across Project SAGE's use cases. An agent approved to compare consumer offers is not necessarily approved to buy. An agent approved to prepare a procurement request is not necessarily approved to onboard a supplier or release payment. An agent approved to purchase a digital service is not necessarily approved to increase its own budget.
Interoperability must preserve control meaning
Interoperability is useful only when control meaning survives the handoff. A receiving institution should be able to determine who the agent represents, the purpose and limits of the delegation, the requested action, the required approval level, the current risk state, and where responsibility and remedy sit.
A portable identity assertion should therefore be accompanied by action-specific evidence. The receiving service should enforce its own acceptance policy and record the result. It should not assume that another participant's recognition of the agent authorizes every downstream action.
Liability needs an evidence chain
Liability cannot be resolved by identifying the agent alone. Reviewers need to reconstruct whether the principal issued a valid instruction, the agent stayed within scope, the institution applied its controls, any required approval was independent, the destination and amount matched, and alerts were handled in time.
Consumer protection also requires a practical pause, complaint, investigation, and remedy path. The evidence map should identify who can stop an active agent, who investigates an exception, who communicates with the affected user, and who can restore service after a safe review.
Practical KYA checklist
- Assign a stable identity, represented principal, accountable owner, version, environment, and lifecycle state to every financial agent.
- Keep identity verification separate from action-specific delegated authority.
- Define permitted goals, prohibited actions, amount and duration limits, approval thresholds, and withdrawal conditions.
- Record each account, wallet, payment method, tool, service, institution, merchant, and data set the agent can reach.
- Require each receiving institution or service to make and record its own acceptance decision.
- Carry mandate and control meaning across system handoffs without exposing more personal or commercial data than necessary.
- Link instruction, interpretation, policy checks, approvals, external calls, execution, settlement, exception handling, and remedy.
- Re-evaluate authority after software changes, new tools, new destinations, unusual behavior, cumulative exposure, or jurisdiction changes.
- Test prompt injection, identity replay, mandate substitution, access expansion, destination changes, repeated small actions, pause, and recovery.
- Map serving entity, permitted activity, liability owner, record period, complaint owner, and legal review date for each market.
Bottom line
Project SAGE puts agent identity and delegated authority directly into the agentic-finance governance discussion. The durable KYA control is not a badge that says an agent is known. It is a current evidence map showing who the agent represents, what it may do, which financial resources and services it may reach, how every material action is reconstructed, how abuse is contained, and where responsibility sits.
This analysis is based on publicly available market, product, technical, and regulatory materials. Detailed collection metadata is intentionally omitted.