Know your agent (KYA)
Know your agent is the practice of confirming that an AI agent acting for a customer is declared, tied to a verified customer and device, and acting within a mandate the customer set. It separates a customer’s approved assistant from automation that only pretends to be one.
An automated session
- Phone
- Her own phone and SIM, bound at sign-up
- Input
- Driven by software, in the pattern her assistant always shows
- Payees
- Two billers and one grocery merchant she usually pays
Pays the electricity bill, ₹2,400
Allow · Her usual patternAsks to pay ₹96,000 to a payee she has never paid
Outside her patternWaits for a face check on her own phone
Step up · Nothing sent
Every automated session answers three questions.
DeepID enrols no agents and holds no mandates. It reads an automated session the way it reads any other: the phone, the input and the payee, against what is already bound to the customer.
Whose phone
Her own phone and SIM, or another device.
The phone and SIM bound at sign-up, and a device fingerprint that survives reinstalls, read whether a person or software is driving. Automation from a device she has never used is a different actor, whatever credentials it carries.
The moduleWhose input
Her own rhythm, her assistant’s pattern, or someone else’s.
Bot, script and AI-agent detection tells a session driven by software from the customer’s own touch and typing, and one automation pattern from another. A script that moves differently from her usual assistant stands out.
The moduleWhose payee
A payee she usually pays, or one linked to mules.
The payee set against the ones she usually pays and against the payee and mule graph. A first-time payee linked to mule accounts carries the same risk however the payment was started.
The module
Allow within her usual pattern. Step up outside it.
Three automated requests, and the decision for each. Whether to allow automation at all, and what an assistant may pay without a step-up, is your policy, tuned per journey.
- Allow
Her usual pattern. Automation from her own phone, to a payee she usually pays, within her usual amounts. The payment goes, with the reasons logged.
- Step up
Outside her pattern. A new payee or an unusual amount. The payment waits for a face check on her own bound phone, and goes only if she approves.
- Block
Not hers at all. Scripted input from an emulator, with no device she has used. The session does not proceed, and the event reaches your FRM.
Six risks agents bring with them.
How payment networks and identity vendors describe the risk, in plain words. Incident data is still thin, so treat these as the questions to ask, not as measured losses.
Delegation abuse
An agent acts beyond what the customer intended: the wrong merchant, the wrong amount, repeat purchases.
Agent hijack
A malicious page or message steers a genuine agent to a payee the attacker controls. Every credential is valid.
Spoofed agents
Bots claim to be a trusted agent to get past bank and merchant defences.
Scale attacks
Agent tooling for credential testing, account creation and synthetic-identity farming.
Coached set-ups
Scammers talk a customer into giving an assistant they control her credentials or a session.
No one to step up
No person is in the session to answer a code or a face check, so the step-up has to reach the customer on her own phone.
Where each check alone gets agents wrong.
A customer’s AI assistant and an attacker’s script both arrive as software with the same valid credentials. Only one is acting for her. Each of these trusts the credential, not the person holding it.
Bot defences
They treat every automated session as hostile, so they block her assistant together with the attacker’s script, or are loosened for both.
Customer authentication
Passwords and one-time codes assume a person is present, so once credentials are handed to software a pass says nothing about what is acting.
Known device checks
An assistant running in her own browser inherits the trusted device, so the check passes for her, her assistant and a hijacked assistant alike.
Transaction monitoring rules
Rules score the amount and the payee against her history and hold no view of what is driving the session.
Six things to ask of any agent scheme.
Agent schemes and the mandates they carry are still being written by payment networks and agent providers. When your bank weighs one, these are the six things a mandate would need to hold. They are questions for the scheme, not features of DeepID.
The customer
Is the person who set it up verified, and did they do it on their own bound phone?
The agent
Is the agent declared, with its device and automation profile, and can its provider attest to it?
Payees
Which billers and merchants may it pay, and what happens to anything else?
A cap
How much per payment and per month, and who approves above it?
An expiry
When does the permission stop, unless the customer renews it?
A record
Is every agent payment logged with its reasons, so “my agent did it” can be answered?
Still being written.
No market on the rule map has a rule written for AI agents yet. The controls this use case calls on are the ones the map already carries: risk checks at every key event, and moving beyond SMS OTP to a check on the customer’s own bound phone. DeepID enrols no agents and claims no integration with any agent scheme.
- The AI agents use case, step by step
- Behavioural biometrics, including bot and agent detection
- SIM and device binding, the phone and SIM the customer is bound to
See DeepID on a real phone.
We show your fraud, security and engineering leads how DeepID would run your sign-up, login or payment journey, then plan a pilot on your own traffic.