A customer lets an AI assistant pay her bills and top-ups each month. Weeks later another automated session arrives with the same valid credentials, adds a payee she has never used and sends a large payment. DeepID tells scripted and agent-driven sessions from the customer’s own rhythm, reads the device and the payee like any other session, and asks her for a face check on her own bound phone before a payment outside her pattern.
Step up
STEP_UP · undeclared automation · first-time payee · amount unusual · face check requestedA customer sets up an AI assistant to pay her bills and top-ups each month. It signs in, moves quickly and never makes a typing mistake. A few weeks later another automated session arrives with the same valid credentials. It adds a payee she has never used and sends a large payment. Both sessions are software, and only the first was acting for her.
An illustrative scenario, not a real customer’s case.
She gives an AI assistant her credentials, or a session, and lets it pay known billers and merchants on a schedule.
Your checks saw
A valid login. Automation detected and blocked, or let through.
DeepID reads
An agent-driven session, read as one: scripted input, from her known device, to the payees she usually pays.
Its sessions are fast, exact and repeatable, with none of the touch or typing variation of a person.
Your checks saw
Automation. Challenged, or allowed as before.
DeepID reads
The same automation pattern, device and payees each time, and the decision is allow with those reasons.
An attacker with stolen credentials runs a script and presents it as her assistant. Or hidden instructions on a page steer the genuine assistant towards a payee the attacker controls.
Your checks saw
Valid credentials. Automation, as before.
DeepID reads
A different device fingerprint, or the known device with a new payee and an amount far from her pattern.
The session adds a new payee and pushes a payment she never approved.
Your checks saw
An authenticated session. Within the account limit.
DeepID reads
One step-up: the payment waits for a face check on her own bound phone, and goes only if she approves.
Each of these trusts the credential, not the person holding it. Read together across the journey, they stop agreeing, and that is what DeepID reads.
They treat every automated session as hostile, so they block her assistant together with the attacker’s script, or are loosened for both.
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.
An assistant running in her own browser inherits the trusted device, so the check passes for her, her assistant and a hijacked assistant alike.
Rules score the amount and the payee against her history and hold no view of what is driving the session.
Bot, script and AI-agent detection tells a session driven by software from the customer’s own rhythm, and one automation pattern from another. A script that moves differently from her usual assistant stands out.
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 payee set against the ones she usually pays and against the mule graph. A first-time payee linked to mule accounts carries recipient risk however the payment was started.
A payment outside her pattern waits for a face check with liveness on her own bound phone. Software can hold her credentials; it cannot pass as her in her own app.
Whether to allow automation at all, and what an assistant may pay without a step-up, is your policy, tuned per journey. DeepID returns the decision with its reasons; it enrols no agents and claims no integration with any agent scheme.
Allow an automated session from her known device to the payees she usually pays, cool off a recognised automation that asks for more than usual, and step up a new payee or an unusual amount to a face check on her own phone. Whether to allow automation at all is your policy.
Automation from her known device, paying a payee she usually pays, within her usual amounts. The payment goes, and the reasons are logged.
A recognised automation asks for more than usual. The payment waits for a set time, and she sees why in the app.
A new payee, or an amount outside her pattern. The payment waits for a face check with liveness on her own phone, and goes only if she approves.
Automation from a device she has never used adds a payee linked to mule accounts. The payment waits, and your fraud team receives the reasons.
Scripted input from an emulator with no known device. The session does not proceed, and the event reaches your FRM.
“Your assistant asked to pay ₹96,000 to a new payee. Nothing has been sent. Approve it with a face check, or leave it and it will not go.”
The same decision reaches your FRM, case manager or SIEM as an event, with one code per reason. The codes here are illustrative; real codes and their names are agreed in the sandbox.
Agreed in writing before the pilot starts, and counted on your own traffic against what you see today. How much of your traffic is already automated can be measured on your own history, in a free retrospective. The step-up and the device signals are proved in a shadow proof on live sessions. We publish no figures for these.
No. It reads the session the agent produces: scripted input, the device, the payee and the amount. Where an agent scheme offers an identity, that is for your policy to read; DeepID claims no integration with one.
A manipulated assistant can still look like her own, so device and input signals alone may not flag it. That is what the step-up is for: a new payee or an amount outside her pattern waits for her face on her own phone, however familiar the automation looks.
No. Your policy can block all automation, allow it from known devices to usual payees only, or allow it within limits. A retrospective shows how much automated traffic already reaches your channels, which helps inform that choice.
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.
Device, behaviour, scam and payee signals read at login, new payee and payment, returned as one decision with its reasons.
One-tap login that tries the network check, the SIM check and Aadhaar consent before any one-time code, and face checks with injection defence where identity is in doubt.
DeepID supports compliance with these rules. It never claims to guarantee it.
Sign-up or login end to end, with the decision back in the app and as an event, so your engineers see the shape of it before anyone signs anything.