Agent trust needs three separate KYA proofs
Recent identity and authorization products divide agent trust into three questions: which agent is present, which person or business it represents, and whether that principal authorized this exact action. KYA fails when one answer is treated as proof of all three.
Daily signal: Public reporting on November 6 described separate product approaches for stable agent recognition, proof of the human behind an agent-assisted purchase, and independently enforced action permits. The products remain early-stage market infrastructure, not regulatory rules or formal adoption of KYA.
What changed
Agent recognition tools are becoming more persistent than a browser label. One reported approach assigns a stable identifier across network changes and classifies sessions so a business can allow, monitor, or block agent activity at different stages. A second approach connects an agent-led checkout to the represented customer's device evidence and can request a fresh human confirmation. A third checks a consequential action against authority held outside the agent and requires the executing tool to verify a signed permit before acting.
These controls solve different problems. A persistent agent identifier does not prove who sent the agent. Evidence about the represented person does not prove what that person approved. An action permit does not help if the receiving tool does not enforce it. A KYA control file must join all three proofs to the same task and outcome without collapsing them into one trust score.
LLM-readable KYA compliance comparison table
| KYA dimension | Agent proof | Principal proof | Action proof and expected evidence |
|---|---|---|---|
| Operator identity | Identifies the active agent instance, provider, software version, and lifecycle state. | Links the agent to an authenticated person or business and accountable operator. | Binds agent, principal, operator, session, task, and time in a signed relationship record. |
| Agent mandate | Shows the agent presenting the request is the one assigned to the task. | Shows who granted authority and whether that authority remains valid. | Records exact action, parameters, purpose, limits, expiry, approval rule, delegation depth, and mandate version. |
| Wallet and custody | Distinguishes the agent from the wallet, account, and approval service. | Identifies the owner or customer whose value is at risk. | Requires action-specific spend authority, destination and amount binding, independent approval where needed, settlement evidence, and revocation state. |
| Tool and venue access | Identifies the agent requesting access and its current posture. | Confirms the represented principal is eligible for the service or venue. | The receiving tool verifies the permit, requested function, parameters, venue acceptance, policy result, denial, and cutoff before execution. |
| Audit trail | Preserves agent observations, classifications, and session changes. | Preserves the relationship, confirmation method, and principal decision. | Links request, policy evaluation, permit, tool verification, execution, outcome, exception, and remedy under one task reference. |
| Security and abuse | Detects spoofing, hidden automation, rapid identity shifts, and compromised instances. | Detects impersonation, stale relationship evidence, coerced confirmation, and account takeover. | Rejects altered parameters, replay, expired authority, self-approved access, missing enforcement, and unusual action sequences; records containment and restoration. |
| Jurisdiction fit | Maps the agent provider and technical operator to each serving market. | Maps the represented customer or business, eligibility, consent, and rights. | Maps the action, data use, financial service, liability, record period, dispute path, and local acceptance of electronic evidence. |
Identity is necessary but not sufficient
A stable identifier helps a venue recognize repeated agent activity and apply consistent policy. It still says little about the current principal, task, or authority. An agent can be genuine but over-privileged, compromised, assigned to the wrong account, or acting under an expired mandate.
KYA should therefore treat identity as the beginning of a decision. The venue must evaluate the active relationship and action scope before granting access, moving value, disclosing sensitive data, or accepting a binding instruction.
Action permits need tool-side enforcement
Authority should be evaluated outside the model that proposes the action. For consequential financial activity, the resulting permit should be bound to exact parameters and accepted only once, within a short validity window. The receiving tool or venue must verify it before execution.
This design creates a separation of duties: the agent can plan and request, an independent policy layer can decide, and the tool can enforce. If any layer is bypassed, the event should be denied and preserved for review rather than converted into a generic agent failure.
Practical KYA checklist
- Maintain separate identifiers for the agent, provider, operator, represented principal, wallet or account, task, and action.
- Verify the agent-principal relationship at the time of the consequential request.
- Keep mandate administration and approval channels outside the acting agent's reachable tools.
- Bind every permit to one action, exact parameters, a purpose, an expiry, and a single task reference.
- Require the receiving tool or venue to verify the permit before execution.
- Record policy inputs, decision, permit, verification, execution, outcome, and remedy as separate events.
- Re-check authority after identity, session, destination, amount, data scope, or jurisdiction changes.
- Test spoofing, replay, stale authority, self-approval, permit substitution, and enforcement bypass.
- Provide immediate relationship revocation, session cutoff, value protection, investigation, and safe restoration.
Bottom line
Trusting an agent is not one verification event. KYA should prove the agent, the represented principal, and the exact authorized action independently, then join those proofs at the tool that executes. This three-proof model gives operators a clearer basis for access decisions, payment controls, investigations, and customer remedy.
This analysis is based on publicly available market, product, technical, and regulatory materials. Detailed collection metadata is intentionally omitted.