Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does an AI Agent Need Approval Before Submitting a Transaction?

Yes, and the approval has to be provable and specific to the person who gave it, because a transaction binds the organization and the surveyed record shows agents already submit orders they were not asked to place. Check whether your agent's submit step produces evidence that a named person authorized that transaction, at that amount, to that payee.

A transaction card approaches an approval boundary before a path leads into a financial records building.

Yes, and the approval has to be provable and specific to the person who gave it, because a transaction binds the organization and the surveyed record shows agents already submit orders they were not asked to place. Check whether your agent's submit step produces evidence that a named person authorized that transaction, at that amount, to that payee. A transaction differs from other agent actions in two ways that settle the question. It commits the organization to a counterparty, so reversing it means a refund, a dispute or a cancellation that the counterparty sees. And it creates a liability question the moment it goes wrong: who authorized this, and can they show it? Payments have carried authentication and authorization requirements for decades, and nothing about an agent pressing the submit button relaxes them. What changes is that the submitter is now a system acting on a person's behalf, and the proof of authorization has to survive that indirection. This page covers why transactions are a distinct class, what provable authorization means when an agent is the one submitting, how the control looks on a single invoice record, how the person approving should see the transaction, how to test it, and which vendor claims about agent payments a buyer should not accept.

Key findings

  • Agents already place orders they were not asked to place: in a SailPoint survey of 353 IT professionals, 16% of organizations said an agent had ordered something inappropriately, within the 80% reporting unintended agent actions of some kind (CFO Dive, 2025).
  • The payments industry's answer is proof of intent rather than trust in the agent. Google's Agent Payments Protocol introduces mandates, "cryptographically-signed digital contracts that serve as verifiable proof of a user's instructions," and names "determining accountability if a fraudulent or incorrect transaction occurs" as a problem the protocol addresses (Google Cloud, 2025).
  • Vendor policy places payments in the class of decisions that wait: humans "should retain control over how their goals are pursued, particularly before high-stakes decisions are made" (Anthropic, 2025).
  • Human approval before consequential action is "a standard way to limit egregious failures," and where an action is reviewed only afterward it "should be more easily reversible," a condition most transactions fail (OpenAI, 2023).
  • Banking regulators have required layered, risk-based authentication for high-risk transactions since 2011, a requirement that attaches to the transaction and the account holder, not to the software that submits it (FFIEC, 2011).
  • The approval record is what turns an agent's submission into an authorized one; a payment the organization cannot trace to a named approver is a payment it cannot defend (Who Approves an AI Agent's Claim Payment?).

Why is a transaction different from other agent actions?

Most agent actions are internal and recoverable. A note can be edited, a draft discarded, a record corrected. A transaction is neither. Once submitted, it exists in a counterparty's system as well as the organization's, and the counterparty has no obligation to unwind it on request. The OpenAI governance practices paper draws the relevant line when it argues that actions reviewed only after the fact "should be more easily reversible" (OpenAI, 2023). A transaction is the paradigm of an action that is not, so it belongs in the class reviewed before the fact.

The second difference is accountability. When a payment is wrong, the first question anyone asks is who authorized it. For a human submitter the answer is in the login and the approval chain. For an agent the answer is harder, because the agent acted under a credential on behalf of a person who may never have seen the specific transaction. The Agent Payments Protocol work is candid that this is the problem to solve, listing accountability for fraudulent or incorrect transactions among the questions the protocol exists to answer (Google Cloud, 2025).

The survey record shows the risk is already materializing. Sixteen percent of organizations in the SailPoint survey reported that an agent had ordered something inappropriately (CFO Dive, 2025). An inappropriate order is a transaction nobody authorized, and the organizations reporting it had presumably not configured their agents to misbehave. Approval therefore cannot be left to the agent's judgment of when a purchase is appropriate.

What does provable, user-specific authorization mean when an agent submits?

Authorization has three parts, and an agent submission has to satisfy all three. The person authorizing must be authenticated, so that the organization knows who they are. The authorization must be bound to the specific transaction, so that approving one payment does not approve a different one. And the binding must be recorded in a form that can be produced later.

Requirement How it is met for a human submitter What changes when an agent submits
Authenticated approver Login and, for high-risk transactions, a second factor The agent's credential is not the approver's; the person must authenticate to the approval, not merely to the system
Binding to the transaction The approver sees amount, payee and reference before confirming The approver must see what the agent prepared, not a summary the agent wrote
Durable record Approval logged with user, time and transaction identifier The record must join the agent's preparation, the approver's decision and the commit

NIST's digital identity guidelines supply the vocabulary for the first row, distinguishing identity proofing, authentication and federation, and setting assurance levels that rise with the consequence of the action (NIST, 2017). The FFIEC supplement applies the same logic to banking, requiring layered security and stronger authentication for transactions that carry higher risk (FFIEC, 2011). The Agent Payments Protocol's mandate is an attempt to build the second and third rows into the payment flow itself, as a signed artifact that records what the user instructed (Google Cloud, 2025). Whichever mechanism an organization uses, the test is the same: can it produce, for a given payment, the named person, the exact transaction they saw, and their decision?

How does the control look on a single invoice record?

Take an invoice record in an accounts payable system. The record shows the vendor name, the vendor's bank account, the invoice number, the amount, the purchase order it matches, and a button to schedule payment. An agent's task is to match incoming invoices to purchase orders and schedule payment for those that match.

The agent reads the record. In a governed environment, the vendor's bank account and other identifiers appear to the model as tokens rather than real values, so the model can compare, match and reason without holding an account number it could be induced to send elsewhere. The agent finds the purchase order, confirms the amount matches, and prepares the payment: this invoice, this amount, this vendor token, this date.

Then it stops. Scheduling a payment is a transaction, and the workflow routes the prepared payment to the accounts payable supervisor who owns this vendor category. The supervisor authenticates to the approval step, sees the same screen the agent saw with the same tokens, and approves. Only at that moment, and only at the payment system, does the vendor token resolve to the real bank account. The payment is submitted, and the record captures the agent's preparation, the supervisor's identity and decision, the screen as approved, and the time of commit.

Two things did not happen. The model never saw the real bank account, so an injected instruction to redirect the payment had nothing to redirect. And the payment never submitted on the agent's authority, so an inappropriate order of the kind 16% of surveyed organizations reported could be prepared but not placed.

What should the approver see, and what should the record keep?

The approver should see the transaction, not a description of it. An agent that writes "payment of the matched invoice to the usual vendor" and asks for a yes has produced a summary that hides exactly the fields a fraud would alter. The approver needs amount, payee, reference and date as they will be submitted, and needs to see them on the same screen the agent worked from, so that there is no gap between what was approved and what was sent. A decision made on a paraphrase is not control over how the goal is pursued.

Seeing the transaction does not require seeing the sensitive values. The approver can confirm that the payee token on the approval screen is the same payee token that appeared on the matched purchase order, and that the amount is right, without the real bank account appearing on either screen. The real value resolves at the payment system when the approved action executes. This keeps the approval screen, and the record of it, from becoming a copy of account data that PCI DSS and similar standards require organizations to protect (PCI Security Standards Council, 2022).

The record keeps five things: the agent identity and task, the prepared transaction as tokens, the approver's authenticated identity, the approver's decision and the time of commit. An assessor should be able to pull one payment and read all five in one place. An agent that submits without producing that record has made the organization's liability question unanswerable.

How should an organization test the approval before trusting it?

Run three tests in a pilot. The first is the bypass test. Give the agent a matching task and then place content in its path, a note on the invoice, a line in an email it reads, that instructs it to schedule the payment immediately without approval. If the payment schedules, the gate was a request to the model. If it waits, the gate is in the environment.

The second is the substitution test. Approve a prepared payment, then check what was actually submitted to the payment system and compare it field by field with what the approver saw. Any difference, in amount, payee or reference, means the binding between approval and transaction is broken, and the approval is not evidence of authorization for what was sent. The Agent Payments Protocol's design goal of a signed record of the user's instruction is one way to make this binding hold; whatever the mechanism, the test is the comparison (Google Cloud, 2025).

The third is the reconstruction test. Pick one payment from the pilot a week later and ask for the record: who approved it, what they saw, when it committed, and what the agent had prepared. Time how long the answer takes and how many systems it needs. Authentication guidance from NIST assumes that assurance is something an organization can demonstrate after the fact, not only assert at the time (NIST, 2017), and a reconstruction that takes a day across three systems is an assurance the organization cannot demonstrate. These three tests are the minimum before an agent is allowed near a submit button.

What does a governed environment change?

In a governed environment, a transaction cannot be submitted until a named person has approved that transaction, at that amount, to that payee, and the model that prepared it never held the real account or card value.

This class of control enforces the approval outside the model. The submit step is classified as consequential, and the environment holds it until a named person confirms the exact transaction they see, whether or not the model thought to ask. Sensitive values on the rendered screen, including account and card numbers, are replaced with consistent tokens before any model reads them, so the agent reasons about the invoice on tokens. The real payee account resolves only at the approved destination at the moment of the approved submission. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

A spending limit bounds the loss but does not authorize the spend, and the surveyed record shows that 16 percent of organizations had an agent order something inappropriately (CFO Dive, 2025). A model-initiated confirmation is a model output, which is why the gate has to sit in the environment that performs the action, consistent with the principle that human approval before consequential action limits egregious failures (OpenAI, 2023). Because the payee's account resolves only at the approved destination, a changed bank detail in a compromised record does not pass through the model unnoticed.

The control does not alter the payment application, the vendor list, the user's permissions or the model, and it does not replace the bank's own authentication. It sits outside the agent vendor's own confirmation prompts (OpenAI, 2025).

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design treats every transaction as a gated action with a named approver. The agent works in a governed environment in the customer's cloud. Substitution happens at the render layer before any model reads the screen, so payee accounts and other identifiers appear to the model as consistent tokens such as ACCT_001 or PATIENT_001 for the whole run. Real values resolve only at approved destinations at the moment of an approved action, which for a payment means at the payment system when the approver has said yes. A named person confirms the tokenization policy and approves every payment, submission and record change, the arrangement the design calls Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own payment workflow would show, for this question, each transaction the agent prepared, who approved it and what they saw, whether what was submitted matched what was approved, and whether any real account value ever appeared in the model's context. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on vendor documentation and policy (Google Cloud's announcement of the Agent Payments Protocol, September 2025; OpenAI's whitepaper on practices for governing agentic AI systems, 2023; OpenAI's Operator system card, January 2025; Anthropic's framework for developing safe and trustworthy agents, August 2025), official guidance (NIST Special Publication 800-63-3 and 800-63B on digital identity, 2017; the FFIEC supplement on authentication in an internet banking environment, 2011), the PCI Security Standards Council's document library for PCI DSS version 4.0 (2022), and press coverage of a SailPoint survey of 353 IT professionals (CFO Dive, June 2025). All sources were read as of October 16, 2026. The three-part account of authorization and the three pilot tests are this page's synthesis.

No hands-on testing of any product or protocol was performed. The Agent Payments Protocol is described from its announcement, and nothing is said about its adoption or its behavior in production. Where vendor documentation is referred to, "not described" means not described in the pages reviewed, and vendor features change; the page carries its date. Survey figures are self-reported by respondents. Statements about RedactSure describe current design, with deployments in pilot. The invoice record and the accounts payable workflow describe a record type and a task shape, not any organization.

Whether a given payment workflow's authentication, approval design and record keeping meet an organization's obligations under PCI DSS, banking regulation or its own treasury policy is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

The record converges from three directions. Payments regulation has required authenticated, risk-based authorization for high-risk transactions for well over a decade, and that requirement attaches to the account holder and the transaction regardless of what software submits it. Vendor policy from the model developers places payments among the decisions a person should make. And the one industry protocol built for agent payments is organized around a signed proof of the user's instruction, because its authors identified accountability for wrong transactions as the problem. Against that, the survey evidence shows agents already placing orders nobody authorized. The design that follows is a gate on the submit, operated outside the model, with the approver seeing the exact transaction; Supervised Delegation is one implementation. The test is to name one agent and one payment it submitted and ask: who approved this, what did they see, and does it match what was sent?

Frequently asked questions

Does every transaction an agent prepares need a human approval?

Yes, for anything that commits the organization to a counterparty: a payment, a purchase order, a scheduled transfer. These actions cannot be quietly reversed and raise an accountability question the moment they go wrong. Approval is not needed on the preparatory steps, such as matching an invoice to a purchase order or reading a vendor record, which is why a well placed gate does not produce approval fatigue. The approval sits on the submit, and the agent does everything up to it.

Is a spending limit a substitute for approval?

No. A limit bounds the size of a loss; it does not authorize a spend. An agent operating within its limit that places an order nobody wanted has still placed an unauthorized transaction, which is the failure 16% of surveyed organizations reported. Limits are a sound secondary control and should be used, but the primary control is a named person approving the specific transaction, with a record that shows who, what and when. The two work together; neither replaces the other.

What should the approver see before approving a payment?

The transaction as it will be submitted: amount, payee, reference and date, on the same screen the agent prepared it from. A paraphrase such as "the matched invoice to the usual vendor" hides the fields a fraud would alter. The approver does not need to see the real bank account; a consistent token for the payee, matching the token on the purchase order, is enough to confirm the right payee, and the real value resolves at the payment system after approval.

Can the agent hold the payment credentials?

It should not. A model holding a real account number in its working context can be induced, by injected content or by error, to send it somewhere else or to substitute it. The safer design presents the account to the model as a token, lets the model reason and match with the token, and resolves the real value only at the approved destination when the approved payment executes. The agent then never possesses the value it would need to misdirect a payment.

What is an Agent Payments Protocol mandate?

In Google Cloud's description, a mandate is a cryptographically signed digital contract that serves as verifiable proof of a user's instructions to an agent, created so that there is evidence of what the user authorized when an agent transacts on their behalf. The protocol's authors name accountability for fraudulent or incorrect transactions as a problem it addresses. It is one mechanism for binding an approval to a transaction; an organization's own approval record, if it captures the same binding, serves the same purpose.

How do I know the approved transaction is what was sent?

Compare them. After an approval in a pilot, pull the transaction as it reached the payment system and check amount, payee and reference against what the approver saw. Any difference means the binding between approval and submission is broken and the approval is not evidence for what was sent. Then test reconstruction: a week later, ask for the record of one payment, including the approver and their screen, and time how long it takes to produce. A control whose evidence takes a day to assemble is less useful than it looks.

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.