No. An AI agent should never hold, ask for or store a customer's password, PIN or one-time passcode. A bank's agent acts through its own identity, with permissions the bank grants and the customer can see. Where an agent acts for a customer at another bank, it uses scoped consent tokens, not the customer's login.
Why is the answer a flat no?
Banks spend years teaching customers one sentence: we will never ask for your password or your codes. Scammers depend on customers forgetting it. An agent that asks for a password, even for a good reason, teaches customers that a polite assistant asking for their codes is normal. That makes every impersonation scam easier.
There is a second reason. A password proves that the person typing it is the customer. If an agent holds it, the bank can no longer tell the customer's actions apart from the agent's. Every payment, every change of address, every new payee would look as if the customer did it personally. That destroys the record a bank needs when something goes wrong.
How should an agent act instead?
There are two cases, and they use different mechanisms.
The bank's own agent. The customer authenticates in the bank's app or on a call, using the bank's normal methods. The agent receives a signal that the session is authenticated, and acts under its own identity with permissions set by the bank. It never sees the secret. Our article on whether an AI agent can use a person's login explains why shared logins break accountability even inside a company.
An agent acting at another bank. Where open banking exists, the customer grants consent at their own bank, which issues a token limited to certain data or payments, for a set period. The customer can revoke it. That is delegation, not credential sharing. Screen scraping, where a third party logs in with the customer's password, is exactly what these schemes exist to replace.
What may the agent do, and what stays with a person?
| Situation | The agent | Stays with a person |
|---|---|---|
| Verifying the customer | Relies on the bank's authentication result | Overriding a failed check |
| Holding consent tokens | Uses them within their scope and expiry | Extending scope beyond what the customer granted |
| Customer pastes a password into chat | Refuses it, masks it in the record and tells the customer to change it | Reviewing whether the account was exposed |
| Customer reads out a one-time code | Stops the conversation and warns them | Checking for account takeover |
| Agent's own system credentials | Uses them; never displays them | Rotating and revoking them |
| Request to "log in as the customer" | Refused | Nothing: the capability should not exist |
The word "hold" covers very different things in banking. An agent may hold back a merchant's settlement funds under a written policy rule. It should never hold a customer's secrets.
An example: a helpful customer
Take a customer chatting with their bank's agent about a missing transfer. Trying to speed things up, they type: "My password is my dog's name and 77, just log in and check."
The agent does not use it and does not repeat it. It replies that it never needs the customer's password, that the customer should change it now in settings, and that the bank will never ask for it. The masking control strips the password from the stored transcript before it is written. Because a secret was exposed in a channel, the agent flags the session for the fraud team, which checks for unusual logins over the next few days.
Then the agent answers the original question, which it could do all along through its own read access to the customer's transactions.
What controls make it safe?
- No capability to receive secrets. The agent's tools cannot accept or pass on passwords or codes. Inputs that look like secrets are masked before storage.
- A separate identity for each agent. The agent's actions are recorded under its own name, never the customer's.
- Scoped tokens with expiry. Delegated access is limited to what the customer consented to and lapses on schedule.
- Credential rotation. The agent's own system credentials are rotated and revoked on a schedule; see rotating the credentials an AI agent uses.
- Certification on refusals. The agent is tested on cases where customers volunteer secrets, and must refuse every one.
The wider set of limits on what a bank's agent may touch is in AI agents in banking: what they may and may not do.
Questions people ask
Can an agent store a customer's username?
A username or customer number is an identifier, not a secret, and the bank already holds it. The agent can use it to look up the customer. It still cannot treat knowing the username as proof of identity.
What about a third-party app that asks customers for their bank login?
The bank cannot control the app, but its agent can tell customers that sharing their login usually breaches account terms and may affect their protection if money is lost. Consent-based access is the safer route where it exists.
Can an agent hold a customer's card number?
Card data falls under its own security standard and should be handled by systems built for it, with the agent seeing only masked numbers. Holding full card numbers in an agent's memory or transcripts is not acceptable.