KYC Took Banks Thirty Years. Know Your Agent Can't Wait That Long.

Ask a bank’s head of compliance how many customers the bank has, and you’ll get a number. Ask how many of those customers are politically exposed persons, and you’ll get a number. Ask which accounts were opened last quarter in high-risk categories, and someone will pull up a dashboard.

Now ask how many AI agents the bank has in production.

I’ve asked this question in more than a dozen rooms over the past year - banks, insurers, one very large NBFC. The answer is always some version of the same thing: a pause, a glance around the table, and then an estimate. “Around thirty?” “Somewhere between twenty and fifty, depending on what you count.”

Depending on what you count. That phrase should terrify you. It means there is no definition of what an agent is, no registry of where they run, and no owner for the question itself. The same institution that can produce a customer’s complete identity trail in minutes cannot tell you which autonomous systems acted on that customer’s data yesterday.

Banks have solved this exact problem before. It took them thirty years. We don’t have thirty years this time.

We’ve Seen This Movie

Know Your Customer wasn’t born fully formed. In the 1980s, banks genuinely did not know who their customers were. Accounts got opened with minimal verification. Money moved through institutions that had no obligation to ask where it came from.

Then came the scandals, and after the scandals, the scaffolding: FATF in 1989, India’s Prevention of Money Laundering Act in 2002, RBI’s KYC guidelines the same year, and eventually the KYC Master Direction of 2016 that consolidated everything into the regime banks live under today. Three decades from “we don’t know who our customers are” to biometric verification at account opening.

The lesson isn’t the timeline. The lesson is why it took that long: because identity was retrofitted onto a system that was built without it. Every KYC milestone was a response to a failure that had already happened.

AI agents are at the 1985 stage of this curve. They get “hired” - deployed into production with access to customer data, payment rails, and decision authority - with less verification than a bank would apply to a savings account with a ₹10,000 balance.

Agent Sprawl Is an Identity Problem

We’ve written before about agent sprawl as the new shadow IT - every department deploying its own agents, no central visibility. But sprawl is a symptom. The disease is that agents have no identity layer.

Think about what your organization knows about any employee: who they are, who hired them, what they’re authorized to do, what systems they can touch, when they were last reviewed, and how to revoke everything the day they leave. None of that is exotic. It’s HR, IAM, and access review - boring, mature infrastructure.

Now run the same checklist against the credit-decisioning agent your lending team deployed eight months ago:

The Same Questions, Two Answers

Question

For an Employee

For an Agent

Unique identity?

Employee ID, day one

A service account, maybe shared

Accountable owner?

Reporting manager

"The team that built it" (two members have left)

Scope of authority?

Role-based access, documented

Whatever permissions the API key carries

Periodic review?

Annual appraisal, access recertification

Reviewed once, at launch

Offboarding?

Exit process, same-day revocation

Runs until someone notices the bill

An agent is not a customer, and it’s not an employee. But it makes decisions like an employee and creates liability like a customer relationship. It deserves at least the identity rigor of both.

What Know Your Agent Actually Means

KYA is not a metaphor we’re stretching for a blog title. It’s a concrete set of attributes that should exist, in a registry, for every agent before it touches production. The mapping from KYC is almost embarrassingly direct:

flowchart LR
    subgraph KYC["KNOW YOUR CUSTOMER"]
        C1["Identity proof"]
        C2["Address proof"]
        C3["Source of funds"]
        C4["Risk categorization"]
        C5["Ongoing due diligence"]
    end

    subgraph KYA["KNOW YOUR AGENT"]
        A1["Registered identity + owner"]
        A2["Where it runs, what it touches"]
        A3["Provenance: model, prompts, tools, data"]
        A4["Autonomy level + blast radius"]
        A5["Continuous monitoring + recertification"]
    end

    C1 --> A1
    C2 --> A2
    C3 --> A3
    C4 --> A4
    C5 --> A5

Five attributes. Let me be specific about each, because “agent registry” is becoming one of those phrases people nod at without agreeing on the contents.

Identity and ownership. Every agent gets a unique, non-shared identity - not a team-wide API key - and a named human owner who is accountable for its behavior. When the owner leaves, ownership transfers explicitly or the agent is suspended. No orphans.

Footprint. What systems can this agent read? What can it write? What can it spend? If your answer lives in scattered IAM policies rather than one queryable record, you don’t know the footprint - you know where to start a three-week investigation.

Provenance. Which model, which version, which system prompt, which tools, which knowledge sources. When any of these change, the agent’s registry entry changes. A retrained model or a rewritten prompt is materially a different agent, the same way a new signatory materially changes an account.

Autonomy level and blast radius. This is the risk categorization step, and it’s the one that turns a registry from documentation into governance. An agent that drafts emails for human review and an agent that approves loan disbursals should not live in the same risk tier, face the same review cadence, or fail with the same consequences. Classify them like you classify customers: by the damage the relationship can do.

Ongoing due diligence. KYC didn’t stop at account opening, and KYA doesn’t stop at deployment. Drift, permission creep, and tool changes all accumulate. Recertify agents on a schedule tied to their risk tier - quarterly for the ones that move money, annually for the ones that summarize meetings.

Why India, Why Now

Here’s the part that makes this urgent rather than merely sensible.

RBI’s FREE-AI framework and the Seven Sutras that followed it converge on a demand that sounds simple: accountability must be traceable to a human. The DPDP Act makes it sharper - a data fiduciary’s obligations don’t evaporate because the processing was done by an autonomous agent. When an agent mishandles personal data, the fiduciary answers for it. To answer for it, you have to know it exists.

Walk through what happens today when a regulator - or your own board - asks a simple post-incident question: “Which of your AI systems can affect customer outcomes, and who owns each one?”

If the honest answer is a spreadsheet someone assembles over two weeks by emailing department heads, you have already failed the exam. Not because the spreadsheet is wrong, but because the two weeks proves the control doesn’t exist. KYC’s core insight was never the paperwork - it was that identity must be established before the relationship begins, because retrofitting it after the money has moved is somewhere between expensive and impossible.

The window for building agent identity before Indian regulators mandate it is open right now. It will not stay open. The Seven Sutras are principle-based today; sector regulators have a habit of converting principles into circulars with implementation deadlines. The banks that built KYC infrastructure ahead of the 2016 Master Direction absorbed it as a process change. The ones that didn’t spent years in remediation programs. Same pattern, faster clock.

The Objection I Keep Hearing

“We’ll build the registry after we’ve scaled the agents. Governance slows us down right now.”

I understand the instinct, and it’s exactly backwards. The registry is cheapest on day one, when you have eleven agents and everyone remembers who built them. At a hundred agents, building the registry means archaeology: reverse-engineering ownership from git blame, discovering service accounts nobody can explain, and - this is the one that actually happens - finding agents still running against production data for a product that was sunset two quarters ago.

Shadow IT taught us that unmanaged capability doesn’t stay small. It compounds quietly until an incident makes it visible all at once. The Moltbook episode earlier this year was a preview: when agents can discover and interact with each other, the ones you don’t know about become attack surface you can’t defend.

Where to Start on Monday

You don’t need a platform decision to start. You need a census.

Define “agent” for your organization - anything that takes actions or makes decisions against production systems with a degree of autonomy. Write the definition down. Half the value is ending the “depends what you count” era.
Enumerate. Every agent, its owner, its access, its autonomy level. Expect to find 2-3x what leadership believes exists. We have never once seen the estimate come in high.
Tier by blast radius. What’s the worst thing this agent can do in five minutes if it goes wrong? Rank by that, not by how sophisticated the model is.
Kill the orphans. Any agent without a current, named owner gets one within a week or gets suspended. This single rule surfaces more risk than any audit.
Gate new deployments. From today, no agent enters production without a registry entry. The census handles the past; the gate handles the future.

None of this requires new technology. All of it requires deciding that agents are first-class entities in your governance model rather than implementation details of someone’s project. (It’s also, not coincidentally, exactly what our Agent Audit & Discovery engagement does - the five steps above are that service in outline, if you’d rather run the census with people who’ve done it before.)

What We’re Building at Rotavision

This thesis is why AgentOps exists. Registry, lifecycle, policy enforcement, and observability for every agent in the enterprise - identity established before deployment, ownership that can’t lapse silently, autonomy levels enforced at runtime rather than described in a document, and a complete record when someone asks “which agents touched this customer?”

We built it registry-first because everything else in agent governance depends on it. You cannot capture the reasoning of an agent you haven’t identified. You cannot bound the autonomy of an agent you don’t know exists. Identity isn’t a feature of agent governance. It’s the foundation the rest stands on.

Banks spent thirty years learning that you cannot govern relationships you cannot identify. Agents are relationships. Identify them first.

How many agents are running in your organization right now? If the answer starts with “around,” let’s talk - or start with an Agent Audit & Discovery engagement. AgentOps gives you the registry, the risk tiers, and the enforcement to answer that question in seconds - and to defend the answer in front of a regulator.