Researchers Earned $50,000 Hacking AI Support Agents. They Never Ran a Scanner.

Support chatbots used to answer questions from an FAQ. Many of them now act. They read billing records, change account details, work through the support inbox and approve refunds. That is a much bigger job, and in most companies it came without a matching security review.

The short answer: AI customer service agents can be manipulated through the messages they read, not only through bugs in code. At DEF CON 34, researchers used spoofed emails, planted instructions and poisoned knowledge base content to make support agents leak data, bypass MFA and issue refunds. A standard web pentest is not designed to catch this; it calls for AI-specific red teaming.

Through the content they process. At DEF CON 34 in Las Vegas (August 6 to 9, 2026), Inti De Ceukelaire, Founding Member of Intigriti, gave a talk at the Bug Bounty Village on how attackers can trick AI support agents into leaking secrets and acting on behalf of victims. According to Intigriti's write-up, published on September 2, 2026, the research brought in more than $50,000 in bug bounties over a few weekends, without Burp Suite or any automated scanner.

No scanner was involved because none of these flaws were classic code bugs. They sat in the gaps between the model, the email system, the backend and the human reviewer. Five patterns stood out.

The knowledge base was an entry point too. When a crawler indexes community comments or user profile pages on the company domain, an attacker can plant fake instructions or discount codes there, and the agent later cites them as official company content.

Not on its own. If the reviewer and the AI agent see different versions of the same message, or if the conversation history can be forged, the reviewer approves something they never actually saw.

Many teams answer AI agent risk with a single safeguard: a person reviews anything sensitive. The DEF CON research shows why that is not enough.

The researchers' own conclusion was that human oversight does not make a system safe by itself. It fails wherever there is a gap between the point where a person stops making careful decisions and the point where an over-privileged agent takes over.

The best-known ruling so far says yes. In Moffatt v. Air Canada (2024), a Canadian tribunal held the airline responsible for incorrect information its chatbot gave a customer and rejected the argument that the chatbot was a separate legal entity.

The chatbot told a customer he could apply for a bereavement discount after travel, while the airline's actual policy did not allow retroactive claims. The British Columbia Civil Resolution Tribunal found Air Canada liable for negligent misrepresentation and awarded C$650.88 in damages, the difference between the bereavement fare and the price he paid, plus interest and fees. The amount was small. The principle is not: what your bot says and does on your website is yours.

In the EU, the rules are also changing on a fixed date. The new Product Liability Directive (EU) 2024/2853 treats software, including AI systems, as a product covered by no-fault liability. It applies to products placed on the market or put into service after 9 December 2026. Compensable damage now includes the destruction or corruption of data not used for professional purposes, and a product can be found defective because of a cybersecurity vulnerability. Manufacturers also cannot escape liability when the defect comes from a missing software update that was within their control and needed to keep the product safe.

The directive has clear limits. Only individuals can claim under it, and pure economic loss, privacy infringements and data leaks are not covered by the directive itself; GDPR and other regimes still apply to those. Still, if you build and supply AI-powered software to EU consumers, the direction is clear: "we didn't know the agent could be manipulated" is becoming a harder position to defend.

Because the weaknesses are not in the code a pentest examines. They appear where the model, the email layer, the backend and the human workflow meet, and each part can work exactly as designed while the whole system is exploitable.

A classic web application pentest looks for injection, broken authentication and access control flaws. Those tests matter, but most of the DEF CON findings would pass them. The backend worked as designed. The email server delivered mail correctly. The model followed instructions, as models do.

That is why the industry reference for this work is its own list, the OWASP Top 10 for LLM Applications. Several of its core risk categories map directly onto the research: prompt injection, sensitive information disclosure, excessive agency (the agents could issue refunds and change accounts with too little verification) and data and model poisoning (which covers the knowledge base attacks).

Separate untrusted customer content from system instructions, tie identity to a verified session, validate every tool call on the server side, and keep the agent's permissions narrow. Then test it the way an attacker would, across every channel it listens on.

It also helps to normalize email addresses consistently and to block the bot from sending secrets to unverified recipients. In practice, that means asking six questions about your own deployment:

You can only answer these reliably by trying to break the agent the way an attacker would.

The companies in this research did not deploy anything unusual. They connected a model to an inbox, a knowledge base and a few backend actions, which is a common setup for support automation today. The agent did what it was told. The problem was who got to tell it.

If your support bot can change an account, issue a refund or read an inbox, it deserves the same scrutiny as any other system with those permissions. If your agents also use external tools, our earlier piece on MCP prompt injection covers that side of the attack surface.