How Banks Can Let Customers' AI Agents In: Verify the Person Who Authorized the Agent

A customer asks her AI agent to pay a bill. At JPMorgan Chase, that request stops at the door. CNBC reported that agents can read some Chase data, such as balances, if Plaid or another connector holds the customer’s credentials, but they can’t send money or pay a bill, “actions that make an agent useful” (CNBC, 2026).

Your team may be weighing the same decision. Seen through JPMorgan’s choice, it looks like two doors.

Two doors, and what is wrong with both

The locked door is JPMorgan’s. CEO Jamie Dimon, on the bank’s third-quarter earnings call: “We’re not going to allow just any … outside agent to come in inside the company, because it’s just too risky for clients and for JPMorgan.” He added: “You don’t want rogue agents, and it could be thousands of them” (CNBC, 2026).

That concern is fair. At thousands of agents, nobody on your fraud team reviews each one by hand.

The open door is what the bank’s spokeswoman described when she said JPMorgan does “not permit third parties to access accounts by obtaining customers’ banking credentials and logging in on their behalf” (CNBC, 2026). An agent that signs in with the customer’s own username and password gets in. A credential proves that someone has the password. It says nothing about whether the customer chose, today, to hand it to this agent.

The open door gives your team no evidence of the customer’s choice. The locked door leaves the customer’s agent unable to act. CNBC reported “no timeline” for when the bank would have safeguards in place to let agents work directly with accounts, and that bank stocks were hit in September when Meta’s Muse agent topped the download charts, on fears that consumers would use agents to move funds to higher-yielding accounts (CNBC, 2026).

The third option: card the person at the door

A good bouncer does not ban every guest’s friend, and does not wave in anyone holding a wristband. The bouncer asks who sent you, and then looks at that person’s ID.

Carry that over to banking and keep the direction straight. The bot carries no government ID. The person does. The question is not “who is this agent?” It is “who sent you?” — answered by the human, on their own device, at the moment they authorize the agent.

Here is one way to build that moment. The customer taps to give an agent access to an account. Before the agent gets any scope, your system sends the customer a verification link. The customer opens it, scans a government-issued ID, and the check runs against the authority that issued the ID. If it passes, the agent gets what the customer authorized. If it doesn’t, nothing happens.

Trusona does not inspect the agent. It checks the person.

What the person check consists of

The checks, in trusona.com’s own words:

• The IDV API (AAMVA+) “checks driver’s license details against state DMV records over AAMVA” (Trusona, integrations page). Asked whether it runs a selfie or liveness check, the IDV API page answers: “It verifies the document against the issuing authority instead of matching a face.”
• Scanning can happen “in your own app or in the mobile browser” (Trusona, IDV API page).
• The ATO Protect API (ATOP API) sends the person “a verification link by text or email” and has them scan their ID (Trusona, integrations page).
• The homepage lists “No pre-registration” and “No app download,” and the IDV API page lists “No PII stored.”

For this use case the combination matters. A customer who has never heard of your agent policy can complete the check on a phone they already own, and the result rests on the state DMV’s record, not on how convincing the license looks.

The liability question

Dimon’s other line is the one for your counsel: “If people are using them, they should understand the risk. They should understand there’s a liability transfer” (CNBC, 2026).

In Trusona’s view, shifting responsibility to the customer is easier to defend when the bank can show the customer passed an ID check at the moment the agent was authorized, rather than relying on a password anyone could have held. That record does not settle who pays, and your legal team still writes the terms. It does mean the first question in the file has an answer.

Where this approach stops

Four limits, stated plainly.

The customer needs a government-issued ID to present. Customers without one need another path.

The check is a point in time. It confirms who authorized the agent. It does not watch what the agent does next, so you still need scopes, spending limits and a way to revoke access.

It checks the person and not the agent. Deciding which agents your bank will accept at all remains your policy decision.

And the placement is yours. The IDV API page describes confirming “a real person behind a government ID at onboarding or step-up.” Whether granting an agent access to an account counts as a step-up in your flow is a design call for your team, and the right starting point is a conversation with Trusona sales, not a number in a blog post.

Frequently asked questions

Should banks block customers’ AI agents? Blocking is a legitimate position. JPMorgan Chase currently blocks external AI agents from operating on behalf of retail customers, citing risk to clients and the bank (CNBC, 2026). The cost is that the agent can’t send money or pay a bill. The alternative is to admit agents on a condition, and the condition worth testing is proof of the person who authorized the agent.

Does Trusona verify AI agents? No. Trusona verifies the person. The check confirms that a real person stands behind a government-issued ID, using the issuing authority’s records. Where that check sits in your flow, including the moment a customer authorizes an agent, is your team’s design decision.

What does the customer do, and is there a selfie? They open a verification link on their own device and scan their ID. There is no selfie match: the IDV API page says it “verifies the document against the issuing authority instead of matching a face.”

Which Trusona products run the person check? The IDV API (AAMVA+) and the ATOP API. See the IDV API page and the integrations page for what each does today.

Where can I read about verifying the person behind an agent inside a company? See verifying the human behind an AI agent, which covers the enterprise and help desk case.

Trusona’s IDV API (AAMVA+) and ATOP API check the person against the authority that issued their ID, with no selfie and no PII stored. If you are deciding between a locked door and an open one, talk to sales about where the person check fits in your authorization flow.

Don’t block agentic AI. Ask for the True Persona behind it.