Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is It Safe to Let an AI Agent Issue Refunds?
No, not while the agent reads the refund screen itself: it carries the customer's name, email, address and the card's last four digits, and the amount field takes what the run types. Tokenize those values before the model reads the screen, cap the amount, and put a named person on every refund above the cap.
A support queue holds a $120 refund that a customer has asked for twice. The order is real, the payment cleared last week, and the work is one page away: find the payment, open the menu, choose the amount, pick a reason, submit. An agent that can work that page saves a person four minutes and takes on a decision that moves money out of the account. The screen it reads carries the buyer's name, email and address, the card's brand and last four digits, the order history and an amount field the processor will accept up to the original charge. Whether the run is safe turns on what that screen hands the model. A confirmation dialog does not settle it, because a hijacked run can click the dialog. What changes the answer is a rendered page where the buyer's values are tokens, an amount cap the run cannot exceed, and a person whose name sits on every refund above the cap. The worked record is one $120 refund on a card order, read from the pages Stripe and Shopify publish for their own refund screens. A refund of that size is small enough to automate and large enough to matter, so a support lead should settle its controls before an agent submits one.
Key findings
- For a refund agent to be governed rather than trusted, the values on the refund screen would have to be replaced with consistent tokens before any model reads it, so the run works from ORDER_8821 and CUST_014 while the buyer's name, email and last four digits stay out of its context (What Is an AI Control Record?).
- It would also require a named person approving every refund above a set amount, with a record that shows what the model received on the screen and who released the money (What Is Supervised Delegation?).
- Stripe's and Shopify's refund pages do not state what a model reading the screen receives, and both leave the amount to whoever fills the field (Stripe, Refund, 2026; Shopify, 2026).
- Stripe's page states that "By default, you'll issue a full refund. For a partial refund, enter a different refund amount," and that a refund can only go back to "the original payment method used in a charge" (Stripe, Refund, 2026).
- Shopify's screen lets the operator "Edit the amount in the Refund amount field" and pick a refund method, and a refund there cannot be cancelled or reversed (Shopify, 2026).
- OWASP calls excessive agency "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM," which is the risk a refund permission hands an agent that reads a customer's message (OWASP, LLM06, 2025).
What does an agent read on a refund screen?
Stripe's Dashboard route begins on the Payments page, where the operator finds the payment, opens the overflow menu and selects "Refund payment" (Stripe, Refund, 2026). The screen that follows is the payment record: the amount, the customer's name and email, the card's brand and last four digits, the date and any earlier refunds against the same charge. The amount arrives as a full refund, and a partial refund is a number the operator types into the field (Stripe, Refund, 2026). Only 6 of the 15 AI agents reviewed document asking a person before completing a payment or purchase, which is the check a refund needs before the card is credited (Do AI Agents Ask Before Making a Payment?).
Shopify's screen is longer because a store order is more than a payment. The operator opens the order, enters the quantity, decides whether to "deselect Restock items," can refund shipping, selects a method, edits the amount and can suppress the customer email (Shopify, 2026). The order record beside those fields carries the buyer's name, address and contact details, and the agent reads it to know what to refund. Screen-reading agents of every kind read the page the same way (How to Protect Data From Screen-Reading AI Agents).
For the $120 refund in the worked record, the agent finds one payment, reads the buyer, leaves 120.00 in the amount, chooses a reason and submits. Every field it needed was rendered in the clear, and the value it chose was a text box with a default. That is the shape of the exposure: the card number is absent and the buyer's record is present, so a model that reads the page to find the amount holds the name, the email and the address for the rest of the run.
Can an agent refund by order ID without the card number?
A refund is not a payment. The money goes back along the path it came in, and the destination is set by the original charge rather than by anything the agent types: "Refunds can only be sent back to the original payment method used in a charge" (Stripe, Refund, 2026). That property removes the card number from the task. The agent needs the payment or the order, the amount and a reason, and the processor resolves the rest.
That is the good news, and it is narrow. Stripe bounds the amount at the charge: "you can't refund a total greater than the original charge amount" (Stripe, Refund, 2026). The bound stops one refund from exceeding one charge. It does not stop a partial refund from being sent twice, and it does not decide which charge the agent chose from a list. Shopify's amount is edited by the operator, and the refund that follows cannot be cancelled or reversed (Shopify, 2026).
An agent that refunds through the API instead of the page has a different custody problem, because a key with refund permission is a credential the run holds (Can an AI Agent Manage My Stripe Keys Safely?). The browser path needs no key and no card number. The order is the identifier that matters. Nobody types sixteen digits to send a refund, and no page reviewed here asks for them.
What do the vendors themselves say?
Both vendors document the screen, and neither documents the model. Stripe's refund page covers the Dashboard route, the default full refund, the partial amount, the reason and the note, the bulk path that takes full refunds only, and the return to the original payment method (Stripe, Refund, 2026). Shopify's page covers the order, the quantity, the restock choice, the shipping refund, the method, the amount and the notification, and it sets the permissions the operator needs (Shopify, 2026).
Stripe's role page adds the part a team has to decide before an agent runs. An Administrator "can see and manage almost everything," and roles stack: "If you assign a user multiple roles, they're assigned all the permissions of each individual role" (Stripe, Roles, 2026). A refund agent given an existing login inherits whatever that login holds.
When a refund becomes a dispute, the record widens. Stripe's Dispute object gathers evidence in a hash whose fields include "customer_email_address," "customer_name" and "shipping_address," and "Updating any field in the hash submits all fields in the hash for review" (Stripe, Dispute, 2026). An agent that drafts that evidence reads the customer's contact details a second time.
| Dimension | Stripe, per its documentation | Shopify, per its documentation | What a buyer should verify |
|---|---|---|---|
| How a refund starts | Payments page, overflow menu, "Refund payment" | Orders, order, Refund | Whether the agent's role can open the record at all |
| The amount | Full by default; a partial refund is typed | "Edit the amount in the Refund amount field" | Whether a cap exists outside the page |
| The destination | Original payment method only | A refund method chosen from a menu | Whether any page offers another destination |
| Side effects | The refund alone | Restock, shipping refund, customer email | Which side effects an approval covers |
| Who may act | A role, and roles stack | Store owner or Orders permissions | Whether the agent has its own role |
| What the model receives | Not stated on the page | Not stated on the page | What the model reads, field by field |
Read together, the pages describe a screen built for a person at a keyboard, and neither states what that page hands a model that reads it. That silence is the gap a buyer closes with a test.
What should a security team ask for in writing about the refund screen?
Start with the screen. Ask what the model receives from a rendered refund screen, field by field: the buyer's name, the email, the address, the payment method and its last four digits, the order history and the amount. A vendor that answers only for the API has answered a different question: this agent reads the page the support team uses.
Then ask for the four controls the pages reviewed leave open. A cap on the amount, enforced where the agent acts rather than in a policy document. A named approver above the cap, with authority over the money and not over the run (Do Coding Agents Break Separation of Duties?). The agent's role should be narrower than the team's, because an Administrator's reach is not a refund queue's requirement (Stripe, Roles, 2026). And a record that shows the page the model received beside the approver's name.
OWASP's prompt injection entry supplies the principle: "Restrict the model's access privileges to the minimum necessary for its intended operations" (OWASP, LLM01, 2025). Its excessive agency entry supplies the reason: excessive permissions are a root cause of "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM" (OWASP, LLM06, 2025). A refund tool is a damaging action waiting for a manipulated output, and the rule a whole team needs is in How Do I Set Credential Approval Rules for My Whole Team?.
The design-patterns paper puts the constraint in its strongest form: once an agent ingests untrusted input, "it must be constrained so that it is impossible for that input to trigger any consequential actions" (Beurer-Kellner et al., 2025). A support agent that reads customer messages ingests untrusted input every shift.
What does a governed environment change?
A governed environment acts where the screen is rendered. Values a policy names are replaced with consistent tokens before any model reads the page, so the agent works the refund from ORDER_8821 and CUST_014. Real values resolve only at an approved destination, at the moment of an approved action. A named person approves each refund above the cap, and the record carries every screen, every action and every approval with a name.
For a refund, that changes one half of the risk and leaves the other half to a different control. The customer data leaves the model's context, so an injection that succeeds collects tokens. The amount does not become safe: a tokenized page still shows the agent a number field, and a wrong number chosen there is still a wrong refund. That is why the cap and the approval sit beside the render-layer control.
The scope is the rendered page. An agent that calls the processor's refunds API, or holds a restricted key with refund permission, is outside a browser control and inside the key's own approval rules. Adaptive attacks bypassed 12 published defenses with an "attack success rate above 90% for most" (Nasr et al., 2025), so a classifier in front of the tool is not the guard.
Control placement is the comparison that matters. Check Point's AI Agent Security "secures the AI applications and agents your organization builds and deploys," and its Guard API provides "real-time detection and flagging of prompt attacks, data leakage, content violations, and off-policy agent behavior" on the request path, not the screen an agent reads (RedactSure vs Check Point Lakera).
What the record shows
Values on the refund page are replaced with consistent tokens before any model reads it, which is what makes the first half of this question tractable: the run works from CUST_014 and ORDER_8821, and the buyer's name, email and last four digits never enter its context. A cap and a named approval govern the second half, because the amount is a number the model chooses, and a token in place of a name does not make a wrong amount right. The pages reviewed document that second half and not the first: Stripe fixes the destination and bounds the total at the original charge, and Shopify leaves the amount editable and states that a refund cannot be cancelled or reversed. Neither states what the page hands a model that reads it, which is the question a support team has to answer before it lets one submit. A support lead should check this on one refund: open a $120 order in a test account, capture the page the model receives, and compare it with the approval record and the processor's refund.
Methodology and limitations
This page rests on the refund and dispute documentation Stripe and Shopify publish, Stripe's role page, two OWASP entries from the 2025 Top 10 for LLM applications and two research preprints. Vendor pages were read as of October 22, 2026, and each Sources line carries the date for its page. Public documentation read in full gives a sound view of where each product applies its control, and the refund pages are the record of the flow a support agent follows.
No product on this page was tested hands-on. "Not described in the pages reviewed" means that the recorded pages for a product do not carry the statement, not that the product cannot do it. Vendor features change, and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, one $120 refund on a card order, not an organization. Determinations about whether a refund flow meets a card-scheme, consumer-protection or records requirement belong to counsel, assessors and the organization's own compliance officers.
Frequently asked questions
Is it safe to let an AI agent issue refunds?
No, not while the agent reads the refund screen as the Dashboard or the admin renders it. The page carries the customer's name, email, address and the card's last four digits, and the amount field takes a number the run chooses. Safety comes from three changes: tokens on the rendered screen, a cap the tool enforces, and a named person approving anything above the cap. A confirmation prompt narrows who can click, and it does not change what the model read.
What does the model see on a Stripe refund page?
The values the browser draws: the payment amount, the customer's name and email, the card brand and last four digits, the date, any earlier refunds and a reason field. The amount arrives as a full refund, and a partial refund is typed into the same field on that page. Stripe's page documents that flow and does not describe what a model reading it receives, so the buyer has to test the screen rather than read for an answer.
Can an agent refund without reading the card number?
No. A refund returns along the original path, and Stripe states that refunds "can only be sent back to the original payment method used in a charge." The agent needs the payment or the order identifier, the amount and a reason. The card number never has to enter the context, which is why the exposure on this page is the customer record rather than the card.
Who should approve a refund above the cap?
A named person in the refund queue, with authority to release the amount, and not the engineer who connected the agent. The approval should attach to the specific refund and show what the model read when it proposed it. Stripe's role page lets an Administrator "see and manage almost everything," which is wider than a refund needs, so the approval belongs outside the role rather than inside a broader login.
What record should a refund leave?
One that shows the page the model received, the amount it proposed, the approver's name and the processor's refund identifier. The processor's record proves the money moved; it does not show what the model read before it chose the amount. A record that pairs the two lets a finance team answer a chargeback a month later without reconstructing the screen from memory. The identifier ties the record to the money, and the captured screen ties it to what the model saw.
What happens if the agent refunds the wrong order?
The money leaves, and on Shopify the refund cannot be cancelled or reversed. Stripe bounds a refund at the original charge amount, which stops an over-refund of one charge and does not stop a refund sent to the wrong charge. The dispute that follows asks for fields such as customer_email_address and customer_name, so the case pulls more of the customer record into the run.
How RedactSure Keeps Customer Data Off the Refund Screen
A refund agent that reads the whole page has already seen the customer, and a cap does not take that back.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the payment, reads the buyer's name, email and the card's last four digits, types 120.00 and submits. Inside: the page renders CUST_014 and ORDER_8821, the agent refunds 120.00 against those tokens, the real payment method receives the money only when the team lead approves, and the record shows the tokenized page beside the approver's name.
RedactSure is deploying now with enterprise and government customers. Stripe's own refund field takes any amount up to the original charge, so the cap has to come from the workflow.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A refund is the one support action that moves money, and the screen decides what the model saw. Bring one refund workflow and see, with test values, what the model reads and who approves the release. Book a demo