The AI Agent Is Verified. What Can Go Wrong?

A customer authorizes an AI agent to manage parts of their bank account. The bank verifies the agent, confirms the customer's identity, and establishes what the agent is allowed to do.

Everything checks out.

But what happens if that agent gets tricked into sending money to a scammer? Or if the customer has been manipulated into authorizing a fraudulent payment?

The agent could be legitimate and acting within its permissions, and the customer could still lose money.

We discussed this and other challenges during a recent webinar with About Fraud, featuring:

• Magesh Nepolian, Fraud Director at Fifth Third Bank
• André Ferraz, CEO and Co-Founder of Incognia
• PJ Rohall, Co-Founder of About Fraud

Here are the biggest takeaways for fraud teams preparing for more agent-initiated activity.

A verified AI agent can still commit fraud

When an AI agent accesses a customer's bank account, the first step is establishing which agent is making the request and whether the customer authorized it.

For example, a bank might detect an agent accessing an account for the first time and send a push notification to the customer's mobile banking app.

The customer confirms that it's their agent and approves what the agent can do.

Maybe they want it to check their account balance, review recent transactions, and help organize their finances. They don't want it moving money or making changes to their security settings.

Those permissions define what the agent is authorized to do.

If the agent later tries to transfer money, the bank can recognize that the request falls outside its approved permissions and ask the customer to authorize it.

But even when the agent has the right permissions, there are still ways things can go wrong.

As Magesh explained:

Agent verified does not have to mean customer verified.

And even when the customer is verified, that doesn't mean every transaction is authorized or legitimate.

There are also questions about how long permissions remain valid. Has the customer given the agent more access than it needs? Should an earlier authorization have expired? Has the agent itself been compromised?

These are questions banks need to consider even after an agent has been successfully verified.

Detecting AI agents is going to be an ongoing challenge

Before banks can verify an agent, they need to identify that an AI agent is accessing their systems in the first place.

Some agents make that easier by identifying themselves through mechanisms such as Web Bot Auth, which allows them to sign requests cryptographically.

Others do the opposite.

They change how they present themselves, making it harder to distinguish their traffic from human activity or recognize the same agent across multiple sessions.

André described agent detection as a game of "whack-a-mole."

A bank might successfully detect a particular agent today, only for that agent to change its behavior tomorrow. Even when the bank recognizes that traffic is coming from an agent, it may still need to determine whether it's the same agent the customer previously authorized.

This creates a challenge for financial institutions deciding whether to build or buy agent-detection technology.

Building an initial detection capability may be manageable. Maintaining it as agents change and new ones emerge is much harder.

And this leads to an important consideration for fraud teams: What happens when an AI agent goes undetected?

If your fraud controls depend on identifying the agent before assessing its activity, some transactions may not receive the scrutiny they need.

Banks need to prepare for the possibility that they won't identify every agent accessing their systems.

That means maintaining fraud controls that evaluate the actions themselves, regardless of whether they're initiated by a human or an AI agent.

A suspicious transfer to an unfamiliar recipient should raise concerns in either scenario, for example.

Understanding the intent behind an action

One of André's strongest recommendations is to prioritize intent intelligence.

Intent intelligence is more important than KYA right now.

Know Your Agent (KYA) capabilities help banks identify agents, connect them to customers, and establish what they're authorized to do.

But an agent's identity and permissions can only tell us so much about the legitimacy of an individual action.

For that, we need to look at what the agent is doing and whether it makes sense for the customer.

AI agent fraud has a lot in common with payment scams

Think about what happens in an authorized payment scam.

A customer logs into their banking app using their legitimate credentials, from a device they've used many times before.

They authorize a payment.

From an authentication perspective, everything may look normal. But really, the customer has been deceived into sending money to a scammer.

The same type of problem can happen with AI agents.

An agent might be properly authorized to transfer money, but that doesn't mean the recipient is legitimate.

And the agent itself can be manipulated.

For example, an agent interacting with a website might encounter malicious instructions through a prompt injection attack. Those instructions could cause it to attempt actions the customer never intended, such as downloading malware or initiating a payment to an unintended recipient.

In either case, the bank needs enough information to recognize that something about the transaction is suspicious.

What signals can help banks assess intent?

Fraud teams already use customer behavior and transaction history to identify unusual activity. Those same signals can help evaluate agent-initiated transactions.

Let's say an AI agent initiates a payment to someone the customer has paid many times before.

The amount is consistent with previous transactions, the recipient hasn't changed, and there are no other suspicious signals.

The bank has some evidence that the action is consistent with the customer's normal behavior.

Now consider a different situation.

The agent adds a new beneficiary and attempts to transfer a significant amount of money. There's also evidence of remote access software or suspicious activity on the customer's device.

That's a different risk profile.

Some of the signals discussed during the webinar included:

• Transaction history: Has the customer made similar payments before? Is the amount or frequency unusual?

• Recipient information: Is this an established payee or someone new?

• Device intelligence: Are there signs of malware, remote access tools, or other suspicious device activity?

• Recipient risk: Has the receiving account been associated with potential money mule activity?

• Physical-world relationships: Is there evidence that the sender and recipient have an existing relationship?

Each signal provides part of the picture.

For example, sending money to a new recipient isn't automatically suspicious. But a large transfer to an unfamiliar recipient, combined with unusual device activity, may warrant additional verification.

The same approach applies regardless of if the customer makes the payment directly or an agent does it on their behalf.

How physical-world relationships can help identify suspicious payments

One of the signals we discussed in more detail was the relationship between the person sending money and the person receiving it.

In many legitimate peer-to-peer transactions, there's an existing relationship between the two people.

They may be family members, friends, or colleagues. They might regularly spend time at some of the same places.

These physical-world relationships can provide useful information about whether a payment makes sense.

Incognia's Physical Social Graph uses precise location intelligence, historical location behavior, and persistent device intelligence to identify evidence of those relationships.

For example, two people might regularly spend time at some of the same places, suggesting they may have a relationship in the physical world.

If an AI agent is transferring money between those individuals, that relationship provides additional context about the recipient.

Now consider a payment to someone with no observed physical-world connection to the customer.

That doesn't mean the payment is fraudulent. People make legitimate payments to unfamiliar recipients all the time.

But the absence of an observed relationship can be a useful risk signal, particularly when combined with other suspicious activity.

Our analysis of peer-to-peer transactions has found that:

• 79.2% of legitimate transactions showed evidence of a physical-world relationship between the sender and recipient
• 86.2% of reported scams showed no observed physical-world relationship between the parties

For banks, understanding these relationships can help assess the risk of a payment even when the person initiating it is a verified and authorized customer, or an AI agent acting on their behalf.

Which actions should AI agents be allowed to perform?

Banks also need to decide how much freedom to give AI agents once they've been authorized.

Some actions are relatively straightforward.

If a customer has authorized an agent to check an account balance or retrieve information about a cleared check, those requests may be considered low risk.

Other actions deserve more attention, particularly when they involve moving money or changing account access.

But Magesh raised an interesting point about how banks define low-risk activity:

An individual balance inquiry may be harmless. What if an agent makes hundreds of similar requests in a short period?

That pattern could be an early sign of reconnaissance, with someone gathering information before attempting fraud.

So even activities that are generally low risk need to be evaluated in context.

A practical approach to agent-initiated actions

Here are some examples from the discussion and how banks might approach them.

The risk level ultimately depends on the individual customer, the action, and the available evidence.

For some transactions, the bank may have enough confidence to allow the agent to proceed.

For others, it may need to hold the transaction, perform additional checks, or ask the customer to confirm.

Keep security changes under the customer's control

André was particularly firm about one recommendation during the webinar: AI agents should not be allowed to independently change sensitive account security settings.

That includes passwords, recovery contacts, and similar account protections.

An agent that has been manipulated or compromised could use those permissions to make it easier for an attacker to access the customer's account.

Even if the customer has authorized the agent to perform other banking tasks, changes to security settings should require direct action through an established trusted device.

When should banks bring the human back into the process?

Customers use AI agents because they want to delegate tasks.

If every balance inquiry or routine payment requires them to open their banking app and approve a request, the agent isn't saving them much effort.

Banks need to determine which activities can proceed automatically and when the risk warrants customer involvement.

Adding a beneficiary, changing account permissions, or attempting an unusual payment are examples of situations where additional confirmation may be appropriate.

The importance of a trusted device

When the bank needs to verify an agent's request with the customer, the device used for that confirmation matters.

André strongly recommended using an established mobile banking device.

Mobile applications can provide more stable device intelligence signals than a typical web browser, allowing banks to evaluate the history and reputation of the device.

For example, has this device been associated with the customer's account for a long time? Does it access an unusually large number of unrelated accounts? Has it been connected to previous fraud reports?

These signals can help the bank determine whether the device is trustworthy enough to authorize sensitive actions.

When an agent attempts something that requires additional approval, the bank can send a notification to that device explaining what the agent is trying to do.

The customer can then confirm whether they authorized the request.

This allows agents to handle routine activities without constant interruptions while keeping customers involved in more sensitive decisions.

Sometimes, additional friction is a good thing

Magesh also made a point about customer friction that deserves attention.

Fraud teams often try to reduce the number of times they interrupt customers. But when something suspicious happens, an additional verification step can be valuable.

If someone adds a new authorized user to an account or initiates an unusual transfer, a bank may have good reason to slow things down.

Magesh described how customers may actually appreciate that caution when they understand the bank is trying to protect them.

Of course, how the bank handles the interaction matters.

If a customer believes they've authorized a legitimate action, they may be confused or frustrated when it's challenged.

Fraud analysts and customer-facing teams need to explain why additional verification is necessary without disclosing the details of their fraud detection methods.

And there's another complication: a customer can confirm a transaction and still be the victim of a scam.

If they've been manipulated into believing the payment is legitimate, simply asking them to approve it again may not address the risk.

That's another reason why evaluating the transaction itself is so important.

An AI agent should have to earn trust over time

Once a customer authorizes an agent, how much should the bank trust it?

Our recommendation is to start with very limited trust and build it over time.

When an agent accesses an account for the first time, the bank may know which agent it is and what permissions the customer has granted. But it hasn't yet established a history of the agent's behavior.

That history develops through repeated interactions.

If an agent consistently performs authorized, low-risk activities without suspicious behavior, the bank has more evidence to inform future decisions.

Over time, it may be appropriate to allow that agent to perform additional actions, provided the customer has authorized them.

But that doesn't mean the agent should eventually have unrestricted access.

Whenever it attempts to go beyond its established permissions, the bank should return to the customer for approval.

And even agents with a positive history need ongoing monitoring. A previously trusted agent could still be compromised or manipulated.

Should banks monitor agent behavior differently from human behavior?

This was another question raised during the webinar.

AI agents may behave differently from human customers. They might make requests more frequently or interact with banking systems in ways that would be unusual for a person.

That may justify establishing separate behavioral baselines or risk thresholds for agent activity.

But Magesh cautioned against analyzing those activities in isolation.

Banks have spent years building systems to understand customer behavior, transaction history, and fraud risk.

Some of that information may sit in separate systems that don't share enough data.

As agents become more common, banks need to bring that information together to understand the customer's overall activity.

For example, if a customer begins using an agent to initiate payments, that activity should still contribute to the bank's understanding of the customer's behavior.

The bank needs to recognize how the agent typically operates while evaluating whether its actions make sense for the customer.

How fraud teams can start preparing for AI agents

Banks are at different stages of preparing for agentic AI.

During our webinar, an opening poll found that approximately 30% of respondents didn't have enough visibility to say whether they were seeing an increase in AI agents taking actions on behalf of customers.

Later in the discussion, participants reported varying levels of preparation, from early exploration to actively testing controls.

For fraud teams still figuring out where to begin, several practical priorities emerged from the conversation.

Understand what agent activity you can currently identify.

Start by reviewing your visibility into AI agents accessing customer accounts. How are you detecting them today? Which agents can you recognize, and what happens when an agent isn't detected?

This is also a good time to revisit your vendors' capabilities and understand how they're preparing for agentic traffic.

Review what agents are allowed to do.

Consider which actions customers can authorize agents to perform and whether those permissions are appropriately limited.

Pay particular attention to payments, new beneficiaries, account access changes, and security settings.

Banks should also consider what happens when an agent's authorization expires, is revoked, or no longer reflects what the customer wants it to do.

Evaluate transactions independently of agent verification.

Fraud controls need to assess the risk of an action even when the bank can't confidently identify an AI agent.

That includes looking at customer behavior, recipient relationships, device risk, and other transaction-level signals.

Existing fraud detection capabilities can provide much of this information, especially when signals from different systems are brought together.

Decide when customer confirmation is necessary.

Banks should establish which agent-initiated actions can proceed within approved permissions and which require additional authorization.

For sensitive actions, that confirmation should happen through an established trusted device.

Educate fraud teams and customers.

Magesh's closing recommendation was straightforward: education.

Fraud teams need to understand how AI agents operate, how they can be manipulated, and what suspicious agent activity might look like.

Customers also need to understand the permissions they're granting and the risks associated with giving an agent access to their financial accounts.

As institutions gain experience with agentic activity, that knowledge needs to reach the teams and customers making decisions about how agents are used.

Preparing for agent-initiated banking

AI agents introduce new risks, but many of the questions fraud teams need to answer are familiar.

Does this transaction make sense for the customer? Is the recipient trustworthy? Is the activity consistent with previous behavior? When should the bank require additional verification?

The challenge is answering those questions when an AI agent may be acting on the customer's behalf, sometimes without the institution being able to identify it.

Banks will need to continue developing their agent verification and authorization capabilities. At the same time, strengthening transaction-level fraud detection and understanding customer intent can help protect accounts even when agent identification is incomplete.

As agent activity increases, the ability to make these risk decisions will be essential to allowing legitimate automation while protecting customers from fraud.