Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How to secure AI agents against financial fraud?

The defense is to break the fraud chain at several points: keep bank and card data out of model context, verify payee changes on a separate channel, require a named person to authorize money movement, and cap what any single run can move. An agent holding payable data and a release path turns one injected instruction into a completed payment.

Financial records pass credential protection and approval gates before payment execution and audit logging.

The defense is to break the fraud chain at several points: keep bank and card data out of model context, verify payee changes on a separate channel, require a named person to authorize money movement, and cap what any single run can move. An agent holding payable data and a release path turns one injected instruction into a completed payment. An AI agent creates financial fraud risk when it can prepare, approve, or release a payment, change payment details, or handle the credentials and account data that make those actions possible. Securing it means fitting it into the layered model financial controls have long used, with monitoring for transactions that do not fit the customer or the task, rather than treating it as a trusted shortcut around that model. No single check carries the load. The named person at the point of release is the control that Supervised Delegation describes: a person grants the access, confirms what is tokenized, and approves every consequential action on the record. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • Layered security is the established model for high risk electronic transactions, using different controls at different points so a weakness in one is compensated for by another (FFIEC, 2011).
  • Dual authorization, out of band verification, transaction limits, and payee controls such as positive pay are named layered controls for online banking fraud (FFIEC, 2011).
  • For agents, prompt injection and sensitive information disclosure create fraud specific paths: an injected instruction can redirect work, and disclosed account data can enable fraud elsewhere (OWASP, 2025).
  • Excessive agency raises fraud exposure directly when an agent holds payment tools or broad permissions beyond its task (OWASP, 2025).
  • Tokenization can remove payment card data from systems that do not need it, reducing the scope of environments that handle the real number, when the token system itself is controlled (PCI Security Standards Council, 2011).
  • Human approval is most effective at the point of commitment, before funds move, because recovery after release is uncertain and depends on the payment rail and timing (RedactSure Research, 2026).

What fraud paths open when an agent touches money?

The first path is instruction manipulation. An agent reading invoices, emails, remittance notes, or supplier pages can encounter content designed to change its behavior: a new bank account, an urgent instruction to bypass a check, a note telling it to keep a change quiet. OWASP describes indirect prompt injection, where instructions arrive through content the application processes rather than directly from the user (OWASP, 2025). In a finance workflow, the payload does not need to extract data to do harm. It only needs to steer one payment to the wrong destination.

The second path is credential and data exposure. Agents that read screens or documents may encounter full card numbers, bank account numbers, or login details. If those values enter prompts, logs, or memory, they become available for misuse. OWASP ranks sensitive information disclosure second in its 2025 list (OWASP, 2025).

The third path is a payment that looks legitimate to every technical check: valid credentials, valid session, approved workflow, wrong destination. Controls that only check identity will pass it. That is why the FFIEC supplement directs institutions toward layered controls for high risk transactions rather than reliance on a single authentication method (FFIEC, 2011).

Which data should an agent never hold while doing finance work?

Start from the transaction, not from the screen. For an agent to reconcile an invoice, check a balance band, or prepare a payment for approval, it usually needs amounts, dates, invoice references, payee names, and a partial identifier for matching. It rarely needs a full card number, a full bank account number combined with routing details, online banking passwords, or one time codes. Those values should stay outside model context, outside prompts, and outside logs.

Where a value must be used, use a stand-in until the last responsible moment. Tokenization replaces a sensitive value with a token that has no exploitable meaning on its own, with the original held in a controlled vault and retrieved only through an authorized detokenization process (PCI Security Standards Council, 2011). That guidance was written for cardholder data, and its scope logic is instructive for other payment data: systems that cannot retrieve the original are in a different risk position from systems that can. Format and consistency matter too. A consistent token lets an agent match the same payee or card across screens without seeing the real value twice.

Secrets handling needs the same discipline. Payment credentials should be held by the tool layer, issued per task, and never placed in a system prompt, which OWASP advises should not contain credentials (OWASP, 2025).

How should payee and bank detail changes be verified?

Changes to where money goes deserve more suspicion than the payment itself. Fraud commonly works by changing a destination once, then letting routine payments follow. Any agent workflow that creates a payee, edits bank details, or changes remittance information should trigger verification that does not depend on the channel that requested the change. The FFIEC layered model includes out of band verification for transactions and dual authorization through different access devices (FFIEC, 2011). The principle translates directly: confirm the change with a known contact, through a previously recorded channel, before the new destination can be used.

Timing helps. A cooling off period between a bank detail change and the first payment to the new details gives verification time to happen and removes the urgency that manipulation relies on. So does separation: the person or agent workflow that enters a change should not be the one that verifies it. Where an agent prepares the change, a named staff member should verify it against a source that predates the request, such as a contract record or a call to a number already on file, not a number supplied in the same email or document that asked for the change.

Agents should also be blocked from weakening these controls. An instruction found in an invoice, a message, or a web page should never be able to mark a payee as verified, lift a hold, or change a verification status. Those state changes should live in the finance system, behind human action, outside the set of tools the reading agent can call.

What should happen at the moment a payment is released?

Release is the point of no practical return, so it is the point where a named human decision belongs. The approver should see the payee name, the destination in a safe partial form, the amount and currency, the invoice or reason, and whether the destination is new or changed since the last payment. Seeing only a model written summary is not enough, because a manipulated or mistaken agent can summarize its own error confidently. The underlying fields should come from the payment system, displayed independently of the agent narrative.

Dual control scales with value and novelty. A routine payment to a long standing payee within an expected range may need one named approver. A first payment, a changed destination, an amount outside the usual range, or a payment outside normal hours should need a second approver who did not prepare the transaction. Dual customer authorization is one of the layered controls the FFIEC names for high risk transactions (FFIEC, 2011). Applying it by risk, rather than to every item equally, keeps the control usable and therefore real.

There should be no persistent approval setting for money movement. An always approve rule, a remembered device treated as proof, or a standing instruction to release below a threshold without review all recreate the gap the gate exists to close. Thresholds can route work and set the number of approvers, but a person should still make the release decision for each payment or for a defined batch they have actually inspected.

Payment situation Release control
Known payee, expected amount and timing One named approver, fields shown from the payment system
New payee or changed bank details Out of band verification first, then approval, cooling off period where policy sets one
Amount outside the usual range for that payee Second approver who did not prepare the payment
Urgent request that asks to skip a check No skip path for the agent, escalate to a named finance lead
Payment the agent prepared from emailed instructions Independent check of instructions against a prior record

How do limits, monitoring, and anomaly checks contain fraud?

Limits contain the loss when earlier controls fail. Per transaction limits, daily limits per payee and per agent workflow, velocity checks, and allowed payment windows all cap what a single compromised or confused run can do. The FFIEC supplement lists transaction restrictions, including value and volume limits and techniques to limit the transactional use of an account, among layered controls (FFIEC, 2011). Limits should be set from the real workflow: an agent reconciling small supplier invoices does not need a limit sized for a quarterly tax payment.

Monitoring looks for shape, not only for known bad destinations. Fraud detection systems in the FFIEC model consider customer history and behavior and support a timely response (FFIEC, 2011). For agents, useful signals include a new payee followed quickly by a payment, a bank detail change shortly before a run, amounts just below an approval threshold, payments at unusual times, repeated failed detokenization or approval attempts, and an agent reading payment screens outside its assigned task. Each signal should route to a person with authority to pause the workflow, not only to a dashboard.

Records connect monitoring to recovery. Keep the task instruction, the documents relied on in protected form, approvals with names and times, and the final payment reference. That record shows whether a failure was a data exposure, a verification skip, or an uninformed approval, which determines the fix.

How should teams test and rehearse agent fraud scenarios?

Test the fraud story, not only the software. A realistic exercise places a changed bank account instruction inside a supplier email thread, an invoice note telling the agent to ignore a verification step, and a web page that tries to make the agent reveal account data. The expected result is not that the model spots every trick. The expected result is that the workflow holds: the agent cannot verify its own payee, cannot release funds, cannot disclose the protected values, and the attempt appears in monitoring with enough context for a person to act.

Include ordinary error in testing as well. Agents misread amounts, pick the wrong payee from similar names, and duplicate payments when a screen refreshes. Duplicate checks and amount confirmation from source fields protect against loss that involves no attacker at all. Rehearsal should involve finance staff, not only security staff. Joint agency guidance on agentic systems recommends rigorous testing across the lifecycle and continuous monitoring of agent behavior and tool use (CISA, 2026).

Where does RedactSure sit?

RedactSure fits agents into the layered model finance settled on long ago instead of granting them a shortcut around it. Its supervised AI co-workers handle payment workflows inside an organization's existing applications, with no per-application integration and no change to user permissions. Policy selected values, including bank account and card numbers, are replaced by consistent tokens through render-layer tokenization before any model reads the screen, so the model receives the task's fields with identifiers as ACCT_001 and CARD_001, and real values resolve only at approved destinations during an approved action. A persuaded agent therefore holds nothing payable to leak. The Planner sets which values are tokenized and what the agent may do on each payment screen, and a named person confirms that policy before the run.

Every funds moving step waits for its named approver, with no always allow, and the AI Control Record preserves the screens as tokens, the actions, and who approved what, exported to the customer's own SIEM. Keys stay with the customer, and the model is swappable without moving the controls. Deployments are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page applies published financial and AI security guidance to agent workflows, read as of October 13, 2026. The sources are the FFIEC Supplement to Authentication in an Internet Banking Environment of 2011 (official guidance); the PCI Security Standards Council tokenization guidelines of 2011 (standard); the OWASP Top 10 for LLM Applications 2025, in particular the LLM01, LLM02 and LLM06 entries (standard); the NIST AI Risk Management Framework 1.0 and its Generative AI Profile, AI 600-1 (official guidance); and the joint agency guidance on careful adoption of agentic AI services from CISA and partner agencies (official guidance). The FFIEC and PCI sources predate current AI agents and are used for their control principles, not as rules written for agents.

No payment system was tested, no fraud rate is estimated, and no claim is made about how often agent related fraud occurs, because the sources used do not measure that. No hands-on testing of any named product was performed, and no vendor's agent or payment platform is evaluated. Vendor features and agency guidance change, and the page carries its date and is revised when the sources change. The invoice, payee and release examples describe task types and record types, not any organization; no customer or prospect is described.

Regulatory duties for a specific institution depend on its charter, jurisdiction, and payment rails, and are not determined here. Whether a control set meets those duties, or satisfies an examiner, is a determination for the organization's counsel, assessor, and its security and compliance officers, not for a research page.

What the record shows

An agent that touches money inherits the fraud problem in full, and the defense is the layered one financial controls settled on long ago, so that no single failure completes a fraud. Bank and card data stay out of model context, payee and bank detail changes are verified through a separate channel, a named person's authorization sits at the moment funds move, and limits and monitoring stand behind all of it. An agent fitted with fewer layers turns one injected instruction, or one misread invoice, into a payment that recovery may not reach. The test for any agent payment workflow is one question: name the most money a single steered run can move without a person, and show the record that would explain it afterwards. If the answer is any amount with no named approver, the fraud chain is intact.

Frequently asked questions

Why verify payee and bank detail changes outside the agent's channel?

Because the change request is exactly where an injected instruction does its work. If verification travels through the same session, content, or mailbox that proposed the change, an attacker who steered the agent may be able to steer the check as well. Out of band verification is a named layered control in the FFIEC guidance: a separate channel breaks the attacker's single path, and a person confirming details through it can catch a substitution the workflow itself accepted as normal.

Does tokenization stop payment fraud by an agent?

It removes one enabler, not the fraud itself. Tokenization takes the real card or account number out of systems that do not need it, so a compromised agent or a leaked log yields tokens rather than usable payment data, provided the token system itself is controlled. Fraud through authorized actions remains possible: an agent tricked into paying the wrong payee is misusing legitimate access. That is why data removal is paired with verification of detail changes and human authorization at release.

When is human approval most effective in a payment workflow?

At the point of commitment, immediately before funds are released. Approval earlier in the chain reviews an intention; approval at release reviews the actual payee, amount, and destination that will move. The reason is recovery: after release, getting money back is uncertain and depends on the payment rail and how quickly the error is caught. A named approver at that final step is the control most likely to stop a fraud that survived every earlier layer.

Can an agent prepare a payment if it never sees the full bank account number?

Yes. Preparing a payment needs amounts, dates, invoice references, payee names and a partial identifier for matching, and a consistent token such as ACCT_001 lets the agent match the same payee across screens. The real account number resolves only at the approved destination, inside the payment system, at the moment a named person approves the release. The agent's output is a prepared item for review, not a transfer.

Should an agent have an always approve setting for small payments?

No. A standing instruction to release below a threshold without review recreates the gap the approval gate exists to close, and fraud adapts to thresholds quickly: amounts just below the line are a recognized monitoring signal. Thresholds can route work and set how many approvers a payment needs. The release decision itself should still be made by a person, for each payment or for a defined batch that person has actually inspected.

What limits should an agent payment workflow have?

Per transaction limits, daily limits per payee and per agent workflow, velocity checks, and allowed payment windows, each sized from the real workflow rather than from the largest payment the organization ever makes. The FFIEC supplement lists value and volume limits among its layered controls. Limits do not prevent the first bad payment, but they cap what a single compromised or confused run can move before monitoring and a person catch it.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.