KYC tells you who the customer is. KYB tells you who the company is. KYA — Know Your Agent — answers a newer, more unsettling question: who, or what, is actually making the compliance decision? As AI agents assume responsibility for KYC reviews, transaction monitoring, and SAR triage, regulated institutions need a framework for assessing the trustworthiness of those agents with the same rigour they apply to the humans they replace.
Why KYA is suddenly necessary
Modern AI agents don't just surface recommendations — they act. A transaction monitoring agent might clear thousands of low-risk alerts per hour, route mid-risk cases for human review, and escalate high-risk ones, all without a compliance analyst touching a single record. That speed is the point. But it creates a structural accountability gap: when a regulator asks "who approved that?" after a suspicious transaction slips through, the answer "an AI agent" is not sufficient. Regulators want a name, a version, a decision trail, and a human who owns it.
Compounding this, the vendor market has moved faster than governance. Financial institutions are deploying third-party AI agents into live compliance workflows — KYC decisioning, AML alert triage, customer risk scoring — with limited visibility into how those agents were trained, what instructions they follow, or how they behave under edge conditions. A black-box agent processing regulated decisions is a compliance liability. KYA is the framework that closes that gap.
The four KYA components
1, identity
Every AI agent operating in a compliance workflow must have a registered identity: which model underlies it, which version is currently in production, what system prompt or instruction set governs its behaviour, and what training data — or fine-tuning — shaped its outputs. Just as KYC captures a customer's date of birth and nationality, KYA captures an agent's model lineage. Without this, you cannot reason about why an agent behaves differently after a vendor update.
2, authority
An agent's authority defines the boundaries of what it is permitted to do. Can it clear alerts autonomously, or only recommend? What risk-score threshold triggers escalation to a human? Can it modify customer risk ratings directly, or only flag them for review? Authority should be formally scoped, version-controlled, and reviewed on the same cycle as a human employee's delegated authority matrix. An agent that has been granted authority beyond its intended scope — even unintentionally — is a control failure.
3, observability
Observability is the capacity to reconstruct, after the fact, exactly what an agent saw and why it decided what it decided. This means structured decision logs that capture input features, model outputs, confidence scores, and the policy version in effect at the time. It also means replayability: the ability to rerun a historical decision against an updated model to understand what would have changed. Without observability, an internal audit or regulatory examination becomes an exercise in reconstruction from incomplete records — and that is a position no compliance team wants to be in.
4, accountability
Every AI agent in a compliance workflow must have a named human owner. That person is responsible for approving the agent's authority scope, reviewing its performance on a defined cadence, and acting as the escalation point when the agent encounters a case outside its confidence boundary. Accountability cannot be distributed across a team or delegated to a vendor — there must be a single individual whose name appears on the control documentation. This is not bureaucracy; it is the minimum viable governance structure for an agent making regulated decisions.
"We found our biggest AI governance gap wasn't the model — it was that nobody had written down what the agent was and wasn't allowed to do, or who owned it if something went wrong."
— Head of AI Risk, Tier 2 Bank, Southeast Asia
Assessing a vendor agent
Before deploying a third-party AI agent into any regulated workflow, compliance and technology teams should work through a structured set of questions. On identity: can the vendor provide model version documentation, and do they commit to notifying you before any update that changes agent behaviour? On authority: is the agent's decision scope formally defined in the contract, and can you restrict or expand it without a software change? On observability: does the agent produce machine-readable decision logs that your own audit team can query independently? Is replay supported? On accountability: who at the vendor organisation is the named owner of the agent's behaviour, and what is the incident response SLA if the agent produces a systematic error?
If a vendor cannot answer these questions clearly, that is the assessment result. An AI agent that cannot be interrogated after the fact cannot be deployed in a compliance-critical role.
What this means for compliance teams
- Governance frameworks need an "agent" category. Most existing control documentation covers people, systems, and processes. AI agents that act autonomously on regulated decisions are a fourth category and need explicit treatment in your risk and control self-assessment.
- Vendor due diligence must extend to agent design. Model card reviews, authority scope documentation, and observability commitments should sit alongside the standard security and data-processing assessments in any AI vendor onboarding process.
- Human oversight is not optional — it is structural. KYA is not an argument against AI agents in compliance; it is the architecture that makes them defensible. The goal is human-in-the-loop at the right point, not at every point.
WIDTH's AI Compliance Officer is built around the KYA model: every agent action is logged with decision provenance, authority boundaries are configured per institution and updated without code changes, and each agent instance has a named owner in the control framework. For compliance teams evaluating AI vendors, the KYA checklist above is a practical starting point — and WIDTH is designed to pass it.