A bank does not let a customer open an account because they remember a password. The password proves they are who they were last time. KYC proves they are someone the bank should be doing business with at all — that they exist, that they are not on a sanctions list, that someone is accountable for the transactions, and that the bank will notice if the pattern starts to look wrong. Authentication and KYC answer different questions. A regulated firm needs both.
AI agents are roughly where retail banking sat before the FATF Forty Recommendations. We have authentication and authorisation — the principal-of-record chain handles those — and almost nothing else. There is no industry standard for proving who deployed an agent, what it is, whether it has been banned for misuse elsewhere, who is accountable when it acts, or how its behaviour is monitored over its lifetime. Most regulated estates are running agents that would fail a customer-due-diligence check. This piece is the case for closing the gap.
Key takeaways
- IAM for AI agents handles authentication and scope. KYC for AI agents handles identity provenance, beneficial ownership, ban-list screening, ongoing monitoring, and suspicious-behaviour reporting — the controls that decide whether an agent should be operating in the estate at all.
- The five FATF KYC pillars map cleanly: customer identification becomes signed agent manifests at deployment; due diligence becomes scope and tool-call attestation; sanctions screening becomes a ban-list service for deprecated models and red-team-failed adapters; ongoing monitoring becomes continuous re-attestation against eval suites; SARs become suspicious-agent reports with an automatic kill-switch.
- Beneficial ownership for agents is a graph — end-user, orchestrator service owner, model provider, deploying organisation — and FATF Recommendation 24 is the right structural model.
- Politically Exposed Agents are agents with elevated authority in treasury, HR, procurement, or legal. They warrant enhanced due diligence on the same logic as FATF Recommendation 12 PEPs.
- CBN's Risk-Based Cybersecurity Framework, FATF Rec 10, MAS Notice 626, NDPA Section 65, and EU AI Act Articles 12 and 14 already converge on the same shape. A KYC-for-agents programme today is anticipation, not invention.
The Reframe: Authentication Is Not Identity
The companion piece argued for the principal-of-record chain — every credential carries the human as data, every hop preserves the chain, every leaf system authorises against the human rather than the agent. That solves a real problem. It does not solve every problem.
The chain answers "who caused this action?" It does not answer "should this agent have been doing anything at all?" The first is authentication and authorisation. The second is identity provenance and ongoing trustworthiness — what financial-services KYC has been refining for forty years.
A bank with perfect authentication and no KYC lets verified criminals move money. A regulated firm with perfect agent IAM and no agent KYC is a firm where every action is correctly attributed, including the actions of an agent that should never have been deployed, was running a deprecated model with known data-poisoning susceptibility, was owned by a vendor that lost its safety certification six months ago, and started behaving anomalously last Tuesday with nobody looking. The attribution is clean. The exposure is not.
Pillar 1 — Customer Identification → Agent Identification at Deployment
FATF Recommendation 10 starts with identification: at the moment a relationship is established, the institution captures who the customer is, verifies against reliable independent sources, and records the basis. An institution that does not know who its customer is cannot screen them, monitor them, or report them.
The agent equivalent is identification at deployment. Every agent that enters the estate should arrive with an artefact that says, verifiably, what it is. Minimum content:
- base model identifier and version with checkpoint hash
- fine-tune adapters loaded, with provenance attestations
- prompt set in effect, with version and approver
- tool list and MCP server set the agent can call
- declared purpose in language a regulator would recognise
- deploying organisation and named responsible human
- a signature that binds the above
This is an AI Bill of Materials with an identity wrapper. The AIBOM tells you what the system is composed of; the KYC manifest tells you who is operating it. The same content serves both purposes.
Verification matters as much as capture. The signature should chain to a recognised root — the deploying organisation's key registered with the regulator's directory, or an industry signing authority where one exists. SLSA-for-ML and Sigstore are the obvious infrastructure. The agent's identity is not a name in a config file; it is an attestation that survives an auditor reading it.
The trap that catches most teams: identification is not a one-time event. The manifest changes every time the base model updates, the adapter set rotates, the prompt is revised, or the tool list expands. Each change is, in KYC terms, a new customer relationship. The manifest must be re-issued and re-signed, not edited in place.
Pillar 2 — Customer Due Diligence → Agent Due Diligence
FATF CDD asks "what should this customer be doing, and is the relationship consistent with that?" The bank establishes expected purpose, calibrates monitoring against the expectation, and treats deviations as signals.
Agent due diligence asks the same question. What data is this agent permitted to touch, what tools is it permitted to call, and is its behaviour consistent with the declaration? The principal-of-record chain is load-bearing here. The chain tells you which human caused each action; due diligence asks whether the action was within the declared scope of the agent that carried it.
Three pieces of machinery make this practical. First, the declared scope must be machine-readable — a structured policy listing data classes, tool calls, and action types, not a prose paragraph. Second, every tool call should be evaluated against the declared scope at runtime; the same policy engine that enforces RBAC on the leaf system can enforce scope against the agent. Third, scope changes are events that themselves require due diligence. An agent whose tool list expanded from read-only to read-and-write last month is a different agent than it was last month, and the change should generate the same review a corporate customer expanding its line of business would generate at a bank.
The maturity gradient runs from "the agent's permissions are whatever the developer wrote into the IAM role" to "the agent's permissions derive from a signed scope declaration reviewed at the same cadence as the policy that authorised it." Most production estates are at the first end. Regulated estates need to be at the second.
Pillar 3 — Sanctions Screening → Agent Ban-List Screening
The OFAC list, the UN consolidated list, the EU restrictive measures register, and national PEP lists are the screening substrate of modern banking. Every transaction and every onboarding runs against them. The lists are centrally maintained, signed, widely distributed, frequently updated. The institution does not get to decide who is sanctioned; the institution is obliged to know.
There is no equivalent for AI agents. There should be, and the absence is one of the more striking gaps in the current ecosystem.
What would a ban-list service contain?
- deprecated model versions with unpatched safety failures
- fine-tune adapters that failed industry red-teaming
- model providers whose certifications were withdrawn
- specific agent identifiers — keyed off the manifest signature — associated with incidents at participating organisations
- model families susceptible to specific prompt-injection or data-poisoning attacks not yet mitigated
The list does not need to be operated by a regulator to be useful. The OFAC-equivalent shape is the right one — distributed, cryptographically signed, mirrored by participating organisations, queried on every deployment. ENISA, NIST, MITRE, and the major model providers are all positioned to operate components; CISA's evolving AI-SBOM work is converging on the same artefact set. Someone is going to operate this. The question is whether regulated enterprises participate in defining its shape or inherit whatever shape arrives.
In the interim, build the local version. Maintain an internal banned-models list, banned-adapters list, and banned-providers list. Make every deployment query the list. Re-query nightly. Fail the deployment on a hit and quarantine any agent already running on a hit. This is the institution-level equivalent of subscribing to a sanctions feed before the regulator demands it.
Pillar 4 — Ongoing Monitoring → Continuous Agent Monitoring
KYC is not a single event. The customer is monitored for the lifetime of the relationship, transactions are screened against expected patterns, and changes in behaviour generate review.
For agents, ongoing monitoring catches the agent that was fine at deployment and is no longer fine at runtime. The failure modes are well-understood. Model drift — the same prompt, the same context, increasingly inconsistent outputs as the foundation model updates. Adapter staleness — a fine-tune current against the eval suite three months ago, silently below threshold now. Prompt erosion — small revisions accumulating into a prompt that no longer matches the manifest. Tool-surface expansion — the MCP server set has grown without the manifest being re-issued.
The discipline that catches these is periodic re-attestation. The agent is re-evaluated against its eval suite on a regular cadence; the results are recorded against its identifier and signed; deviations generate review. The eval suite is the equivalent of the bank's transaction-monitoring rules — a structured statement of what good behaviour looks like.
The honest question, which nobody in the industry has yet answered, is what cadence. Banking transaction monitoring is continuous; periodic customer review runs from annual for low-risk to monthly for high-risk. The cmdev working position is that high-risk agents — anything touching financial data, personal data, irreversible actions, or external communication — should be re-attested weekly with continuous output sampling against an automated eval; low-risk agents can be re-attested monthly. The regulator has not specified a cadence; the institution should specify its own and document the reasoning.
What every cadence has in common: the re-attestation result is data, joined to the agent's identifier, stored in the same audit store as the manifest and the principal-of-record chain. The auditor's question — "show me the trustworthiness history of this agent" — is answered by a single query.
Pillar 5 — Suspicious Activity Reports → Suspicious Agent Reports
The SAR regime is the institution's obligation to surface, internally and to the regulator, behaviour that crosses a threshold of concern. The threshold is deliberately vague; the obligation to look is not.
The agent equivalent is the suspicious-agent report. When behaviour crosses a threshold — anomalous tool-call patterns, output drift beyond a tolerance band, repeated failure of safety classifiers, scope violations, principal-of-record chain breaks — the system fires three things at once: an automatic kill-switch on the agent, an internal report to the responsible human, and, where the threshold is sufficient, a regulatory disclosure.
The threshold question will land where banks landed under FATF Rec 20: institution-defined, defensible, documented, audited. The report itself should contain the agent's identifier, the manifest in effect at the time, the behaviour observed, the principal-of-record chain for the actions in question, the eval-suite results from the last re-attestation, and the action taken.
The structural piece that does not yet exist in most estates is the named human accountable for the report. Under NDPA Section 65, the designated DPO is the operational equivalent of an AML MLRO for personal-data incidents; under EU AI Act Article 14, "human oversight" implies an identifiable human capable of intervening. The regulated estate should designate the AI equivalent of an MLRO — a named human, structurally independent of agent operations, with authority to invoke the kill-switch. The role does not need a new title; it can sit with the existing CISO, DPO, or chief risk officer. It does need to be designated.
Beneficial Ownership for AI Agents
FATF Recommendation 24 obliges institutions to identify, for every corporate customer, the natural persons who ultimately own or control the entity. The recommendation exists because shell companies and nominee structures hide accountability, and accountability is the predicate for every other AML control.
Agents have an equivalent problem. Four parties are always involved: the human end-user whose request triggered the action; the orchestrator service owner inside the deploying organisation; the model provider whose foundation model is in the loop; and the deploying organisation itself, including the named responsible human.
For most actions the principal-of-record chain resolves to the end-user, and that is correct for attribution. For accountability the picture is wider. An agent that acted within scope, using a model whose provider had quietly withdrawn a safety attestation, deployed by an organisation whose responsible human had left six months earlier and not been replaced, is an accountability gap the principal chain alone does not surface.
The shape of the answer is a graph. For every agent, a queryable graph names the four parties, the relationships between them, and the timestamps at which each was current. The graph is queryable forwards — for this agent, who is accountable — and backwards — for this responsible human, what agents are they accountable for. When a responsible human leaves, every agent they are accountable for surfaces immediately, and the absence of a designated replacement becomes a finding before it becomes an incident.
This is the same shape FATF Rec 24 imposes on corporate customers, and the same shape post-Panama-Papers transparency registers have institutionalised. Importing the discipline is not novel work — it is recognising that agents are the new corporate entity from an accountability standpoint.
Politically Exposed Agents
FATF Recommendation 12 imposes enhanced due diligence on Politically Exposed Persons — individuals whose position carries elevated authority and therefore elevated risk of abuse. PEPs are not banned; they are scrutinised more closely, monitored more actively, and subject to senior-management approval at onboarding.
The framing transfers cleanly. Politically Exposed Agents are agents with elevated authority in domains where misuse is consequential: treasury, payments, HR, procurement, legal, customer data at scale, regulatory filings, anything that produces irreversible external commitments. These agents warrant enhanced due diligence on the same logic. The base manifest is not enough; senior-management approval is required at deployment, the eval suite is more demanding, the re-attestation cadence is shorter, the threshold for a suspicious-agent report is lower.
The framing is unfamiliar — most teams have not thought of their treasury automation agent as the AI equivalent of a foreign minister — but the discipline is identical to a regime that already works.
Regulatory Parallels Worth Naming
The framing is anticipatory but not speculative. Multiple existing regimes already imply most of the components.
The CBN Risk-Based Cybersecurity Framework for the Nigerian banking sector requires identification of digital actors, ongoing risk assessment, and incident reporting. Applied to an AI estate, those obligations require the artefacts the KYC programme produces.
FATF Rec 10 (CDD) and Rec 12 (PEPs) are the source material the framing borrows from — reasoned discipline rather than prescription, which is what makes them transferable.
MAS Notice 626 codifies customer identification, ongoing monitoring, and suspicious-transaction reporting obligations in unusually concrete language. It is a useful pattern document for any institution drafting an internal agent KYC policy.
NDPA Section 65 designates the data fiduciary's DPO as the responsible human for personal-data processing — the closest existing analogue to the AI MLRO, already in force.
EU AI Act Articles 12 and 14 — both enforceable from 2 August 2026 for high-risk systems — start looking like the AML record-keeping and SAR regimes when you read them next to FATF Rec 11 and Rec 20. Article 14 in particular implies an identifiable human with authority to intervene, which is the SAR-officer role in everything but name. Article 11 and Annex IV require the artefact the deployment manifest, the AIBOM, and the principal-of-record chain together compose.
None of these regimes uses the word KYC. All of them require the same machinery.
The Reference Architecture
The components compose into an architecture at most twelve months from being the default expectation in regulated estates, and at most thirty-six from being the default everywhere else.
The agent identity registry is the system of record for the manifest. Every agent is registered before deployment, the manifest is signed, the registry is queryable forwards and backwards in time, and an unregistered agent cannot be deployed.
The ban-list service screens every deployment and every re-attestation against internal banned-models, banned-adapters, and banned-providers lists. The interface is simple — a hash query against a signed list. When industry-level signed lists arrive, the same interface consumes them.
The continuous verification pipeline runs the eval suite against every deployed agent on the declared cadence, signs the results, attaches them to the registry, and fires an alert on deviation beyond tolerance. This is the agent equivalent of an AML transaction-monitoring system.
The suspicious-agent reporter aggregates the alerts, applies the institution's threshold, fires the kill-switch, notifies the named responsible human, and produces the report artefact. It joins data from the eval pipeline, the principal-of-record chain, the runtime tool-call logs, and the registry. The output is a single document the auditor can read.
The beneficial-ownership graph is the connective tissue. Every agent in the registry is linked to its end-user population, its orchestrator service owner, its model provider, and the responsible human. The graph is queryable in both directions and updated as ownership changes.
Underneath all of it sits the principal-of-record chain from the companion IAM piece. Identity flows through the credentials, every action is attributed, and the KYC layer reads the chain to produce the artefacts the regulator will ask for.
What Regulators Haven't Decided Yet
Several pieces of the framing are not yet settled. Honest about that.
The re-attestation cadence is not specified anywhere. Banking transaction monitoring is continuous; KYC review is periodic; neither maps cleanly. The cmdev working position is weekly for high-risk and monthly for low-risk; we do not expect this to be the final answer.
The threshold for a suspicious-agent report is not specified, and will likely be left to institutions to define. The same was true for SARs for two decades before guidance hardened. Regulated estates should be defining their thresholds now, defensibly and in writing.
The criteria for Politically Exposed Agent designation are not specified. The treasury and HR domains are obvious; the long tail is not. The institution should make the call itself and revisit it quarterly.
The standard for ban-list distribution does not exist. The OFAC-equivalent shape is the obvious one. The operator could be ENISA, CISA, the FSB, an industry consortium, or a regulator. Participating in defining its shape is more valuable than waiting for it to arrive.
What is not uncertain is the direction. Authentication is solved at the design level. KYC is the next problem. The institution that builds the discipline now is the institution that finds the regulatory clock has already moved before it lands.
FAQs
How is KYC for AI agents different from IAM for AI agents?
IAM handles authentication and authorisation — who the agent is acting for, and what it is permitted to do once it gets there. KYC handles identity provenance and ongoing trustworthiness — who deployed the agent, what it is composed of, has it been banned anywhere, is its behaviour drifting, and who is accountable when it acts. The principal-of-record chain from IAM feeds the due-diligence pillar of KYC, and the KYC artefacts answer questions the IAM chain cannot.
Is there actually a ban-list for AI agents today?
Not at industry level. ENISA, CISA, NIST, MITRE, and the major model providers hold pieces of the substrate, but no signed, distributed, frequently updated list exists in the OFAC sense. Regulated estates should build the local version now, queryable on every deployment and re-queryable nightly, and participate in defining the shape of the industry-level list when it arrives.
What re-attestation cadence does cmdev recommend?
Weekly for high-risk agents — anything touching financial data, personal data, irreversible actions, or external communication — with continuous output sampling against an automated eval suite. Monthly for low-risk agents. The regulator has not specified a cadence; the institution should specify its own, document the reasoning, and revisit it as the threat model evolves.
Who should be the named responsible human for an agent?
The role does not need a new title. It can sit with the existing CISO, the DPO designated under NDPA Section 65, or the chief risk officer, depending on which function has the operational authority to invoke a kill-switch and the structural independence to file a report. What matters is that the human is named in the manifest, the authority is real, and the chain of succession is in place when the human moves on.
How does this map onto the Nigerian regulatory landscape?
The CBN Risk-Based Cybersecurity Framework requires identification of digital actors, ongoing risk assessment, and incident reporting; applied to an AI estate, these obligations require the agent identity registry, the continuous verification pipeline, and the suspicious-agent reporter the KYC framing describes. NDPA Section 65 designates the data fiduciary's DPO as the responsible human for personal-data processing, which is the closest existing analogue to the AI MLRO role. Neither regime uses the word KYC; both require the machinery.
Companion Content
- IAM for AI agents: delegation, principal scoping, and the audit chain
- AI Bill of Materials (AIBOM): SBOM for the model, prompt, RAG corpus, and adapters
- The EU AI Act: enforcement after the August 2026 deadline
- DSPM meets RAG: data classification for the knowledge base era
- Self-improving agents: the SIA production pattern
How to Engage
If you are running an agent estate that needs KYC discipline before the regulator arrives — or building one and want to wire the controls in structurally rather than retrofit them — talk to us at creativeminds.dev/contact.