Know Your Customer (KYC) is the foundation of financial regulation. Banks verify who their customers are, understand their business, and monitor for suspicious activity — continuously, not just at onboarding.
Autonomous AI agents are now performing the same functions as financial counterparties: executing trades, processing payments, managing accounts, submitting regulatory filings. The question regulators are asking is: how do you Know Your Agent?
This guide explains how KYC principles translate to AI agent governance — what "identity", "due diligence", and "ongoing monitoring" mean when the counterparty is autonomous software.
Traditional KYC was designed for humans. You collect identity documents, verify them, assess risk, and continue monitoring. The process works because:
Agents change all three assumptions:
Kakunin's approach: give each agent a cryptographic identity (X.509 certificate), establish a behavioural baseline during onboarding, and continuously monitor against that baseline — exactly as traditional KYC monitors customers after onboarding.
Traditional KYC: collect legal name, date of birth, address, government ID.
Agent equivalent:
const agent = await kakunin.agents.create({
name: 'trading-bot-eu-v3', // unique, human-readable name
metadata: {
version: '3.1.0', // software version
model: 'gpt-4o', // LLM provider + model
framework: 'langchain@0.2.1', // orchestration framework
deployment: 'kubernetes', // runtime environment
operator: 'Acme Capital Ltd', // legal entity operating the agent
regulated_entity: true, // is the operator a regulated firm?
purpose: 'algorithmic_fx_trading', // what is this agent for?
},
});This creates a permanent record in Kakunin's registry. The agent's identity is tied to a cryptographic certificate, not a string name that can be spoofed.
Traditional KYC: assess the customer's business type, expected transaction volume, source of funds, and PEP/sanctions status.
Agent equivalent — before issuing a certificate, Kakunin assesses:
| KYC Factor | Agent Equivalent | How Assessed |
|---|---|---|
| Business type | Agent purpose (trading, payments, data analysis) | Declared at registration; verified by scope |
| Transaction volume | Expected event frequency and size | Declared limits; enforced in certificate scope |
| Source of funds | Authority granted by operator's system | Operator tenant verification |
| PEP/sanctions | Operator entity compliance status | Tenant-level compliance check |
| Risk appetite | Anomaly threshold configuration | Set during agent setup |
Higher-risk agent types (high-frequency trading, cross-border payments) require tighter scope limits and lower anomaly thresholds.
Just as high-risk KYC customers receive enhanced scrutiny, high-authority agents require enhanced controls:
// Standard agent — lower authority
const standardAgent = await kakunin.agents.getCertificate(agentId, {
validityDays: 365,
anomalyThreshold: 0.75,
scope: {
maxTransactionSize: 1000,
allowedActions: ['read', 'report'],
},
});
// High-authority agent — enhanced controls
const hfTradingAgent = await kakunin.agents.getCertificate(agentId, {
validityDays: 90, // Shorter validity — more frequent re-verification
anomalyThreshold: 0.65, // Lower threshold — flag anomalies earlier
requireHumanApproval: {
aboveAmount: 50000, // Human in the loop for large trades
outsideHours: true, // Require approval for out-of-hours activity
},
scope: {
maxTransactionSize: 500000,
allowedMarkets: ['EUR_USD', 'GBP_EUR', 'EUR_CHF'],
allowedCounterparties: ['bank_a', 'bank_b', 'ecb_repo'],
geographicRestriction: ['EU', 'UK'],
},
auditLevel: 'verbose', // Log all intermediate reasoning steps
});Traditional KYC: transaction monitoring, alert generation, periodic review.
Agent equivalent:
// Every agent action is evaluated against its behavioural baseline
const behaviorEvent = await kakunin.events.record({
agent_id: agentId,
action_type: 'trade_executed',
metadata: {
market: 'EUR_USD',
size: 45000,
direction: 'buy',
counterparty: 'bank_a',
execution_time_ms: 234,
},
});
// Kakunin returns risk score for this event
const { risk_score, anomalies } = behaviorEvent;
if (risk_score >= 0.75) {
// Pre-revocation warning already sent via webhook
// On-call paged
// Action logged at verbose level
}The monitoring loop is continuous — not periodic as in traditional KYC refresh cycles. An agent operating 24/7 generates hundreds of events per day, each scored against the established baseline.
Mapping traditional KYC customer onboarding to agent deployment:
# CLI equivalent of collecting KYC documents
kakunin agents create \
--name trading-bot-eu-v3 \
--purpose algorithmic_fx_trading \
--operator "Acme Capital Ltd" \
--regulated-entityGenerates:
a_xyz123)Equivalent to KYC risk assessment → set transaction limits:
const scopePolicy = {
maxTransactionSize: 100000, // EUR
maxDailyVolume: 5000000, // EUR
allowedMarkets: ['EUR_USD', 'GBP_EUR'],
allowedHours: { start: '07:00', end: '18:00', tz: 'UTC' },
allowedRegions: ['eu-west-1'],
counterpartyWhitelist: ['bank_a', 'bank_b'],
};
const cert = await kakunin.agents.getCertificate(agentId, {
validityDays: 365,
scope: scopePolicy,
});The scope is embedded in the X.509 certificate as a custom extension — it cannot be modified without re-issuance from Kakunin's CA.
Equivalent to KYC onboarding period — observe behaviour before applying full controls:
// Enable agent with permissive anomaly detection
// Log everything; block nothing
await kakunin.agents.setMode(agentId, {
mode: 'observe',
duration: '14d',
collectMetrics: ['transaction_size', 'frequency', 'market_concentration', 'time_of_day'],
});
// After 14 days, review collected data
const observationReport = await kakunin.monitoring.getObservationReport(agentId, {
window: '14d',
});Equivalent to KYC compliance officer review:
const baseline = deriveBaseline(observationReport);
// Compliance officer (or automated approval for lower-risk agents) confirms
await kakunin.monitoring.setBaseline(agentId, {
...baseline,
approvedBy: 'compliance@acme.com',
approvedAt: new Date().toISOString(),
});Full anomaly detection active. Any deviation from approved baseline generates an alert.
Kakunin uses a risk-based approach — identical to the risk-based approach mandated for KYC by FATF and EU AML directives — to calibrate control intensity:
Category A — Low Risk
Category B — Medium Risk
Category C — High Risk
Category D — Critical Risk
Traditional KYC: periodic refresh (annual, or triggered by risk events).
Agent equivalent — certificate renewal with re-assessment:
// 30 days before certificate expiry, Kakunin sends renewal reminder webhook
// Renewal requires fresh assessment — not automatic rollover
const renewalAssessment = await kakunin.certificates.startRenewal(agentId, {
// Review if scope is still appropriate
reviewScope: true,
// Pull 12-month behaviour history for baseline re-calibration
recalibrateBaseline: true,
// Check if operator's regulated status has changed
refreshOperatorRisk: true,
});
if (renewalAssessment.scopeChangeRequired) {
// Compliance officer must approve new scope
await notifyComplianceTeam(renewalAssessment);
}
// Issue renewed certificate (may have updated scope)
const newCert = await kakunin.certificates.renew(agentId, renewalAssessment.id);At any point, Kakunin can produce a KYC-equivalent evidence package for an agent:
const evidencePackage = await kakunin.compliance.getEvidencePackage(agentId);
// Contains:
// - Agent registration record (who created it, when, for what purpose)
// - Certificate history (all certs issued, their scope, validity periods)
// - Scope justification (what limits were set and why)
// - Baseline approval records (who approved, when, what baseline)
// - Full audit log (WORM — every action, signed, with risk scores)
// - Anomaly history (all alerts generated, resolutions, times)
// - Revocation events (if any, with reasons and post-incident reports)This package satisfies:
| Dimension | Traditional KYC | KYC for Agents |
|---|---|---|
| Identity document | Passport, company registration | X.509 certificate (cryptographic) |
| Identity verification | Manual review | Cryptographic signature verification |
| Due diligence timing | Onboarding + periodic refresh | Continuous; every action |
| Alert threshold | Rule-based (transaction amount, geography) | ML-based anomaly score against behavioural baseline |
| Response to alert | Human review, possible account freeze | Automatic certificate revocation; agent halts |
| Audit trail | Transaction records | WORM append-only log with cryptographic proof |
| Refresh cycle | Annual or event-triggered | Certificate expiry (30–365 days) |
| Revocation | Manual account suspension | Automatic; propagated in real-time via OCSP |