Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can an AI Agent Approve Expense Reports Safely?
No, not while the agent reads the report screen, because the reimbursement account, the receipt images and the card transactions render beside the amount and the category. Ask for tokens on the rendered page before the model reads it, a named person approving the release, and a record of what the model received.

For a finance team, expense reports are the task most likely to reach an agent first. The queue is long, the decision compares a receipt with a policy line, and the person who makes it holds a limit rather than a budget. One report renders the employee's name, the card transactions behind it, the merchant and the date on each line, the receipt images, the cost center and the reimbursement settings, and a model that opens the page receives all of it.
For the controller who answers for the approval, the gap between the decision and the screen is where the answer sits. Within policy an approval is narrow: the amount against the limit, the category against the policy table, the receipt against the line, the report against the duplicates already filed. The values that make the check possible are not narrow, and they sit on the same page. The pages reviewed answer who may approve and what a payee record requires, and leave open what the model received. A team that can name its approvers and its limits, and cannot say which fields a model read before it approved, holds one half of the control and not the other.
Key findings
- For an agent to approve an expense report safely, the values on the report screen would have to be replaced with consistent tokens before any model reads it, so the card arrives as CARD_018 and the account as ACCT_022 (What Is Supervised Delegation?).
- It would also require a named person approving the release and a record of what the model received (What Is an AI Control Record?).
- None of the pages reviewed states that the values on a report screen are replaced before a model reads them: the Concur guide ends at the Accounts Payable approval (Humboldt State University, 2021).
- BILL's help separates entering a bill from paying it: the Clerk role is "permission to only enter bills" and "A Payer cannot enter or approve bills", a division among people that leaves open what an agent reads (BILL, User roles, 2025).
- Humboldt State University's Concur guide says the "Available Expenses" tab "will show all travel card transactions", and the money moves only once it is "approved by Accounts Payable" (Humboldt State University, 2021).
- An approval logged under the employee's own login does not meet the standard AWS's Agentic AI Lens sets: "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026).
What does an agent read on an expense report screen?
Take one record: an expense report for a four-day customer visit, with three card transactions, a hotel folio, a cost center, a total under the manager's limit, and a reimbursement account on file. That report is the unit an agent would approve.
Humboldt State University's Concur guide describes the first half: the "Available Expenses" tab "will show all travel card transactions", and the employee ticks the transactions (Humboldt State University, 2021). The card lines it shows are the raw material of a report, and the guide is a step sheet for one university's travel card.
Expensify's help describes the other half: a receipt emailed to the workspace means "SmartScan will auto-fill the details and upload the receipt to your Expenses tab", and a scanned receipt can be corrected "to update the merchant, date, total, currency, category, description, attendees, report, or reimbursement settings" (Expensify, 2026). The list ends on the reimbursement settings, where the account the money returns to is chosen.
A model that opens the page receives the rendered fields, not a summary chosen for the decision.
| What the report screen renders | Why the approval needs it | What it exposes |
|---|---|---|
| Merchant, date and card transaction | Matched to the receipt line | The employee's movements and client relationships |
| Receipt image | Proves the purchase | Whatever the document contains, including text nobody in finance wrote |
| Reimbursement settings | Pays the employee | The account number the money reaches |
What does approving within policy decide, and what does it leave open?
Within policy the decision is short. Expensify's help shows the checks a policy engine runs: per diem "must be enabled by a Workspace Admin", and expenses are flagged as duplicates "only when both the date and amount of two (or more) expenses match exactly" (Expensify, 2026). Each check reads an amount, a date and a category, and none of them needs the card number or the account. The policy table supplies the limits, and nothing else is required.
That is the narrow half, and it explains why an agent can plausibly take the routine queue: most reports are approved because the amount sits under a limit, the category is allowed and the receipt matches. A report can be approved within policy on amounts, categories and flags, and no card number is needed.
The screen does not narrow with the decision. The page that supplies the amount also supplies the transaction lines, the receipts and the reimbursement settings, and the model reads it. An agent that approves two hundred routine reports in a month has read two hundred sets of receipts and account settings. The exposure is cumulative in a way the decision is not, and it does not end at the approval: the values stay in the transcript and in the vendor's retention.
An auto-approval removes the person from the loop, not the data from the screen, and the record shows a state change with no name on it.
What do the vendors themselves say?
BILL's help separates what a role may enter from what a role may pay: the Clerk role is "permission to only enter bills", "A Payer cannot enter or approve bills", and "The Accountant role can manage the payables processes, but cannot pay bills" (BILL, User roles, 2025). Administrators, the same page says, "typically have signing authority on your bank account because they can authorize bill payments". The separation runs between people holding different roles, and it says nothing about what an agent with one of those roles reads on the page it approves.
BILL's ePayment page shows what a person sees of a payment record: a user who entered the bank details sees "the last four digits of the bank account, and the full routing number" (BILL, ePayment, 2025). Masking a value in a person's view is not tokenizing it before a model reads the page.
Plaid's Auth documentation shows what a token covers: "Only the numbers.ach[].account field can be set as a TAN", and "TANs are only valid for the ACH and RTP payment rails" (Plaid, 2026). A tokenized account number covers one field, and only Chase, PNC and US Bank use one.
The same BILL page adds a step that matters for an agent: anyone who pays "must complete identity verification to become authorized to use the bank account in BILL", and that step presumes a person at the keyboard.
Who approves a report above policy, and what does the approver see?
Above the limit the report goes to a person, the last control in the chain. Humboldt State University's guide says the money is recovered only once the report is "approved by Accounts Payable" (Humboldt State University, 2021).
What the approver sees is the report as the system renders it, which is the same field set the agent read. The approver reads the agent's summary and the lines behind it, and the distance between a summary and the page is where an injection does its work. That is why a manual approval mode does not settle this question: it governs which actions the agent may take, not which values it read before proposing one (What Does Manually Approve Mode Do in Claude in Chrome?).
The Agent Payments Protocol gives the approval a stronger form: its mandates are "cryptographically-signed digital contracts that serve as verifiable proof of a user's instructions", and the page names "Determining accountability if a fraudulent or incorrect transaction occurs" among the problems they address (Google Cloud Blog, 2025). Signed proof of what a person authorized is evidence about the instruction rather than about what the model read.
An approval on a phone is still an approval. The question is whether the person approves a release of real values or a description of one.
What should a finance team ask for in writing?
Ask what the model receives from a rendered screen, field by field, and write the answer down before the agent is connected. The pages reviewed answer the person's side and leave the model's side open, so name fields, not features.
The first question is about the screen: which fields does the report page render to the model, and are the receipt images and the account among them? The second is the token: is the replacement consistent across the report, the approval and the payment? Consistent tokens let an agent compare an amount with a receipt and still not hold the account, and consistent pseudonyms reduce semantic utility errors by a factor of five (Does Masking Data on Screen Break Browser Agents?).
The third is about the release: name the person who approves the moment the real account resolves, and confirm that the agent's approval waits for that person. A confirmation prompt does not answer it: one vendor's documentation states that data masking for models is disabled for agents (Which Enterprise AI Agents Can Work on Screens With PII Today, and What Does Each One Read?).
The IRS instructions set out what a requester's electronic W-9 system generally must do, including "Ensure the information received is the information sent, and document all occasions of user access that result in the submission" (Internal Revenue Service, 2026).
What does a governed environment change?
The control this question turns on is a property of the environment, not of the agent: the values on the rendered page are replaced with consistent tokens before any model reads the screen, and the real values resolve only at the approved destination. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers.On a report, the transaction lines render with tokens such as CARD_018, the reimbursement account as ACCT_022, and the merchant as VENDOR_003. The policy check runs on the amount, the category and the receipt flag.
The approval attaches to the release. A named person approves the moment the real account resolves, and the approver sees the same tokens the agent saw, so the page in front of the approver and the page the model read agree. Every screen, action and approval with a name exports to the organization's own monitoring as a record.
The limit is the rendered page. An agent that reaches the expense system through a direct API call, a terminal or an MCP tool is outside this control, and an expense estate that spans a report tool, an ERP and a card portal has three screens. A hosted browser shows why: the agent observes browser screenshots and decides the next action from what it sees (Who Controls What an AI Agent Sees in a Hosted or Sandboxed Browser?).
An identity gateway answers who the agent acts for, and leaves open what the model read on the report screen (RedactSure vs Silverfort: 2026 Comparison & Alternative).
What the record shows
Controllers should treat an approval as only as good as the rendered screen the model read before it, and only as accountable as the person named for the release. The pages reviewed settle the second half: a report reaches Accounts Payable for approval before the money is recovered (Humboldt State University, 2021). They are quiet on the first half: none states that the reimbursement account or the receipt images are replaced before a model reads the report page. That leaves the routine approval bounded in decision and unbounded in data. The finance team should test this on one report: list every field the page renders, and ask the vendor which the model receives and which are replaced. If the reimbursement account and the receipt images are on the list, the answer to the title is no until they are off it.
Methodology and limitations
The vendor facts come from help and guidance pages for BILL, Plaid, Expensify and the SAP Concur process at Humboldt State University, plus the IRS instructions and the EchoLeak paper. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read as of October 22, 2026, and each Sources line carries the date for its page.
No product on this page was tested for this page, and no vendor was interviewed. "Not described" here means the recorded facts for a page do not contain the behavior, not that a product cannot do it. Vendor features change, and the page carries its date. The example describes a record type, an expense report with its card transactions and receipts, not an organization. RedactSure is deploying now with enterprise and government customers. Compliance determinations belong to the organization's counsel and its own security and compliance officers, and nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
Can an AI agent approve expense reports safely?
No. Not while it reads the report screen, because the reimbursement account, the receipt images and the card transactions render on the same page as the amount and the category. The pages reviewed document who may approve and what a payee record requires, and none states that the values on the report page are replaced before the model reads them. The condition that changes the answer is a screen that carries tokens, a named approver for the release, and a record of what the model received.
What does the model receive when it opens a report?
The rendered page carries the employee's name, the transaction lines, the merchant and date on each, the receipt images, the cost center and the reimbursement settings, and Expensify's help lists the fields a scanned receipt fills, including the report and the reimbursement settings (Expensify, 2026). The field set is the exposed data set, and it is larger than the approval decision needs.
Who approves a report above the manager's limit?
A person approves, and the Concur guide settles a report only when Accounts Payable approves it (Humboldt State University, 2021). BILL's help places payment authority in a role whose holder has signing authority on the bank account (BILL, User roles, 2025). What that person approves is the report as the system renders it, which is the same page the agent read. An approval that names no person is a configuration, and a configuration is not a control.
What record should an approval leave?
One that answers both questions, because AWS's Agentic AI Lens asks that "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026), and an approval logged under the employee's own login fails that test. The record should carry the fields the model read, the action it proposed, the person who approved and the time. The second question is the one most approval records leave out.
Is an automatic policy check the same as an approval?
No. A policy check compares an amount, a date and a category against a rule, and the duplicate check fires only when both the date and amount of two (or more) expenses match exactly (Expensify, 2026). That is a useful bound and it is not a person. When the check auto-approves, the report moves without anyone answering for it, and the record shows a state change rather than a decision.
Can a receipt image hijack the agent that reads it?
Yes. A receipt is a document a merchant or an employee supplied, and the model reads it as content, which is the route the EchoLeak researchers documented, where the client "automatically fetches the external image URL included by the attacker" (Reddy and Gujral, 2025). The bound that helps is what the model can act on, not only what it can read.
How RedactSure Keeps the Reimbursement Account Off the Report Screen
A report can be approved on amounts and receipts, and the page also carries the account the money returns to.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent opens the report and the model receives the transactions, the receipts and the reimbursement settings. Inside the governed environment the same report renders with CARD_018, ACCT_022 and VENDOR_003, the approver sees those tokens, and the account resolves at the payment the approver releases.
RedactSure is deploying now with enterprise and government customers. BILL's help shows a person's view carrying the last four digits and the full routing number.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
An approval on a report decides who answered for the reimbursement, and the page decides what the model keeps. Bring one report and see, with test values, the page as the model reads it, the approval and the record. Book a demo