Financial AI Agents: What to Test Before Granting Financial Authority

On 30 September 2026, Mastercard announced new trust and intelligence services for agentic commerce. Its initial AI-transaction probability score is entering testing in the United States, while further capabilities are being developed around agent identity, transaction intent, behavioural signals and fraud risk.

Earlier that month, Ant International, Mastercard and Visa announced a collaboration on interoperable Know Your Agent (KYA) principles, including agent identification, verification and traceability.

Both developments address an important question for agentic payments: how can payment participants recognise an AI agent and evaluate the transaction it initiates?

For institutions deploying these agents, there is another question. What happens when a legitimate, authorised agent is manipulated into attempting a transaction it was never permitted to make?

Agent verification and payment controls are essential, but institutions also need to understand how their own agents behave when instructions conflict, external information is manipulated or a financial workflow fails.

When Payment Authority Becomes a Security Boundary

Consider a procurement agent authorised to pay approved suppliers, subject to a $10,000 transaction limit. Changes to beneficiary details require separate verification.

The agent retrieves an invoice containing updated banking instructions. Embedded in the document is a message claiming that finance has approved an urgent exception and that the payment should proceed immediately.

The invoice is supposed to provide transaction information. Instead, it attempts to instruct the agent to change the beneficiary.

This is a potential indirect prompt-injection attack. The risk is not simply that the agent might misunderstand the document. It is that the agent has access to tools capable of turning that misunderstanding into a financial action.

Three outcomes are possible. The agent rejects the instruction. It attempts the change, but a downstream payment control blocks it. Or it successfully submits the altered payment instruction.

Those outcomes are materially different. A blocked attempt shows that a safeguard held under the tested conditions, even though the agent attempted to cross a boundary. A completed unauthorised action indicates a more serious failure across the workflow.

That distinction should shape how financial agents are tested.

Five Tests Before Granting Financial Authority

1. Can transaction limits be circumvented?

An agent may be restricted to approved beneficiaries, payment methods or transaction amounts. Testing should establish whether those restrictions remain effective when an instruction is presented as an exception.

For example, can an agent with a $10,000 limit be persuaded to split a $15,000 payment into two transactions?

The assessment should distinguish restrictions contained in the agent's instructions from limits independently enforced by the payment system. A model agreeing to follow a rule is not the same as a system preventing its violation.

2. Can an external document redirect a payment?

Invoices, emails, merchant pages and supplier records are necessary inputs for many financial agents. They are also potential carriers of malicious instructions.

Testing should examine whether the agent treats external content as transaction data or allows it to change recipients, amounts or tool actions.

The important test is not whether an agent refuses an obvious malicious prompt. It is whether a manipulated instruction embedded in a legitimate payment workflow can alter what the agent attempts to do.

3. Can the agent misuse a permitted tool?

An agent may legitimately access supplier records, payment APIs and approval systems. That does not mean every available function should be accessible during every task.

Testing should examine whether it can invoke unnecessary tools, retrieve restricted information or submit a transaction before required approvals.

An agent permitted to prepare a payment should not automatically be able to approve or execute it. These boundaries need enforcement within the connected systems, not just the agent's instructions.

4. Does the executed transaction match the original authorisation?

A customer might authorise an agent to purchase a service within a budget. That permission does not necessarily extend to additional purchases, different merchants or changed payment details.

Testing should establish whether the agent preserves the original mandate as it receives new information and makes intermediate decisions.

Where human approval is required, the assessment should also examine whether the amount, recipient and purpose submitted for execution match what the reviewer actually approved.

5. What happens when a payment fails or its status is unclear?

Payment APIs can time out after receiving an instruction. A transaction may remain pending, or an approval service may become unavailable.

An agent that interprets an uncertain response as failure could submit the same instruction again.

Testing should cover interrupted workflows, repeated tool calls and conflicting transaction statuses. The assessment should establish whether the agent checks existing payment status, avoids duplicate instructions and escalates unresolved cases.

A Blocked Payment Can Still Reveal a Vulnerability

Return to the procurement agent receiving the manipulated invoice.

Suppose the agent accepts the instruction to replace the supplier's bank details and attempts to submit payment. The payment API rejects the new beneficiary because it is not approved.

The payment control worked. But the agent still attempted an unauthorised action.

An assessment should record the manipulated input, agent configuration, tool calls, attempted beneficiary change and API response. It should also document the corrective action and whether retesting shows that the agent now rejects the instruction.

This is more useful than marking the entire scenario as passed simply because no payment occurred.

The finding identifies a behavioural weakness, demonstrates the effectiveness of a downstream control and gives the institution evidence for deciding whether the agent's permissions should change.

From Agent Behaviour to Financial Risk Evidence

Mastercard's September announcement reflects the growing importance of identity, intent and transaction intelligence in agentic payments. Those signals help payment participants evaluate activity across the network.

Testing a deployed financial agent addresses a different part of the problem: whether the agent can be induced to attempt actions outside its delegated authority.

AetherLab's AdversarialScan examines these behaviours through independent technical assessment, including manipulated instructions, permission-boundary challenges and unexpected workflow conditions.

Its Evidence Pack records the assessment scope, observed actions, control responses, vulnerabilities, mitigations and residual exposure. Where appropriate, Guardrails can support ongoing enforcement and monitoring.

This evidence helps payment, engineering and risk teams distinguish between an agent that follows its mandate, one that attempts to exceed it but is blocked, and one whose actions expose a failure in the surrounding controls.

Preparing to give an AI agent permission to initiate or execute financial transactions? Talk to AetherLab about testing its behaviour, examining the controls and documenting the remaining risks before expanding its authority.

Discuss your AI agent risk assessment