# A Support Agent Issued a $4,200 Refund After Reading an Approval Nobody Gave

**Summary:** Intigriti's research shows how a forged conversation led to a $4,200 refund. I would let the model prepare an action, but keep identity checks and authorization in ordinary software.

- Canonical: https://markhuang.ai/news/support-agent-fake-approval-4200-refund
- Language: en
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-09-14
- Section: News
- Tags: AI Customer Service, AI Agents, Prompt Injection, Application Security, Authorization
- Source: [Intigriti](https://www.intigriti.com/researchers/blog/hacking-tools/hacking-ai-customer-service-agents)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![One email splits into a benign human-facing path and a dangerous machine-action path before reaching an authorization gate](https://cdn.markhuang.ai/news/support-agent-fake-approval-4200-refund/hero.webp)

*One message can look harmless to a person and still send a different signal through the agent's tool path. The authorization gate has to distrust both views.*

[Intigriti's September 2 research on AI customer-service agents](https://www.intigriti.com/researchers/blog/hacking-tools/hacking-ai-customer-service-agents) includes a blunt example: an attacker typed a fake prior approval into an email thread, the support console rendered it as if an operator had written it, and the agent issued a $4,200 refund. Intigriti says the wider research behind its DEF CON 34 talk earned more than $50,000 in bug bounties over a few weekends.

My read is that the model is only one part of the failure. The mail system may understand a message one way while the support console and account API understand it another. Once the agent treats each interpretation as a trusted fact, a display trick can turn into an authorized action.

I would not ask a customer-service model to decide whether a person is authenticated or whether a refund is allowed. It can gather context and propose the next step. The systems behind it must make the security decision from canonical identity and policy data.

## The refund began with two views of one message

The fake-approval example is part of a larger pattern in the Intigriti post. One email can carry an HTML body that a person sees and a different plain-text body that an agent consumes. Invisible HTML can leave instructions available to a machine reader. A remote image server can even return different content according to who fetches it. In each case, the review screen may omit the evidence that influenced the agent.

This is why "a human checked it" is too vague to count as a control. Which representation did the human check? Did the reviewer see the exact identity, source material, tool arguments, and action the agent used? If the console prettifies quoted text into a trusted-looking message bubble, the interface may hide the very distinction the reviewer needs.

The source also documents parser disagreement outside the model. In one example, an email address containing a parenthesized comment was normalized by the mail layer but then placed raw into a backend query string, where another parser treated part of it as a second parameter. [RFC 5322 defines parenthesized comments in structured email fields](https://datatracker.ietf.org/doc/html/rfc5322#section-3.2.2) and warns that comments in address fields can confuse legacy implementations. The bug appears when two valid interpretations are allowed to decide two different security facts.

## Authentication cannot be a conversation

Several examples in the research attack the handoff between a message and an account. A forged sender can point the agent at the wrong customer. An attacker copied on the reply may receive data meant for that customer. Switching from chat to email or phone can reset a weak verification process. The model may follow its instructions perfectly and still serve the wrong person.

That is an old confused-deputy problem wearing a chat interface. The agent has access because the company gave it access. The attacker supplies text that persuades the deputy to use that authority in the wrong context. A stronger system prompt may reduce obvious failures, but it cannot establish who owns the account or whether the requested action fits company policy.

[OWASP's guidance on excessive agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) puts those checks where I think they belong: downstream systems should validate every request against security policy, tools should run in the user's own authorization context, and high-impact actions should require approval. A refund API should receive a server-derived account identifier and enforce refund limits itself. It should not accept an identity or an approval reconstructed from prose.

I reached the same conclusion when looking at [the trust loop around a screen-driving agent](/news/gemini-computer-use-trust-loop). A prompt can describe what the agent ought to do. Permissions and approval gates decide what it can do.

> **Info:**
>
> My rule is simple: the model may propose an action, but deterministic software must authenticate the customer, bind the action to that customer, check policy, and record the decision. Human approval belongs at the final action boundary, with the raw evidence visible.

## More context can create another attack surface

The research moves beyond live conversations into support inboxes and knowledge bases. In one documented scenario, an agent retained an instruction planted in the inbox, then applied it when a genuine one-time passcode arrived later. In another, a community comment containing a nonexistent promotion entered the retrieval index and appeared in the operator console like an ordinary internal citation.

Customer support needs history, policy documents, and account context to be useful. That makes provenance more important. The retrieval layer has to preserve the difference between a forum comment and a policy page, or between a prior customer message and an operator approval. A genuine email from a third party still does not grant permission to forward its contents.

The [OWASP prompt-injection cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) recommends input and output validation, least privilege, tool-specific parameter checks, monitoring, and human review. I would add one product requirement: every fact shown to the reviewer should retain its source class and trust level. A citation without provenance can make poisoned context look more official, not less.

## These are also ordinary integration bugs

A small [r/netsec discussion of the Intigriti post](https://www.reddit.com/r/netsec/comments/1wae5zc/hacking_ai_customer_service_agents_bug_bounty/) includes the skeptical view that convincing a poorly secured service agent is simply the operator's fault. I partly agree. Many examples combine familiar flaws such as spoofing, weak rate limits, permissive parsers, path traversal, or predictable identifiers with an agent. Calling every failure "AI security" can obscure the ordinary engineering mistake that made it exploitable.

That critique changes where I would fix the problem. The model should be treated as an untrusted planner inside a conventional security architecture, not as the component that repairs weak identity checks around it. Agent testing should include malformed email, conflicting representations, poisoned retrieval content, and cross-channel retries because that is where existing bugs acquire a natural-language control surface.

## What I would allow a support agent to do

I would start with read-only tools and narrow records. The agent can summarize a case, locate an approved policy, draft a response, or prepare a refund proposal. Each tool should expose one bounded operation rather than a general backend request, and it should return only data the authenticated customer is allowed to see.

Anything that changes account ownership, reveals a secret, sends money, or contacts an outside system needs a separate authorization step. The reviewer should see the normalized sender identity, the untouched source message, the account selected by the backend, and the exact proposed action. Logs should preserve both what the model saw and what the tool executed.

The $4,200 refund is memorable. The fix is ordinary access control. A useful support agent can interpret a messy request and prepare the next action, but the backend still has to verify who asked, what account they control, and whether policy permits that action.