AI Customer Service Agents Can Be Hacked to Bypass MFA, Steal OTPs and Expose User Data

Security researchers have demonstrated how vulnerabilities in AI-powered customer service agents can be exploited to bypass identity checks, expose sensitive customer data, exfiltrate one-time passwords (OTPs), and trigger unauthorized account actions.

These findings underscore that the risks go beyond prompt injection; they also stem from flawed integrations among email, authentication, backend APIs, knowledge bases, and human review workflows.

Researchers Ayoub and Inti De Ceukelaire presented their findings at Bug Bounty Village during DEF CON 34, securing over $50,000 in bug bounties across several weekends.

Their work shows how a customer support bot, when given access to inboxes and business tools, can become an unintended proxy for attackers if identity and authorization aren’t independently verified.

Email Becomes an Attack Surface

Many support platforms let customers receive chatbot transcripts via email or continue conversations through their mailboxes. In one documented case, weak validation of the email “From” field enabled an attacker to impersonate a victim to the agent.

The compromised agent could then send a convincing phishing email from a legitimate support address, undermining the trust users place in official support communications.

The risk escalates when an AI agent can use tools to update profile information, view billing records, issue refunds, or transfer data.

If a bot bases authorization on email headers controlled by the attacker rather than on a verified account identity, it may execute actions as if it were the victim. Researchers also found that adding an attacker-controlled address to the CC field could send confidential responses to the attacker.

Another related issue involves inconsistent handling of multiple email headers. Email authentication mechanisms such as SPF and DKIM may validate one sender-related value, while an AI agent uses a different “From” or “Sender” field to identify the account and determine where to send its response.

This mismatch between parsing and trust boundaries can allow an attacker to pass delivery authentication while causing the agent to retrieve another user’s data.

The research also identified methods for bypassing Multi-Factor Authentication (MFA) controls implemented by support agents. One example involved quirks in email address normalization that could lead rate-limit tracking to treat variations of the same address as separate identities, potentially allowing for additional OTP guesses.

This technique depends on specific implementation details and is ineffective if OTPs are regenerated for each attempt or if rate limiting is correctly tied to the underlying account and verification session.

Cross-channel inconsistencies pose another concern. A chatbot may enforce strict OTP attempts, while an interactive voice response (IVR) system might initiate a new verification flow for the same account.

Weak IVR schemes based on caller ID, guessable knowledge-based questions, or reusable OTPs could provide alternative paths around otherwise robust web-based MFA.

Perhaps the gravest scenario is exfiltrating OTPs from a support inbox. An attacker could prime an inbox-monitoring agent with malicious instructions disguised as correspondence from a trusted third-party sender.

If a genuine password reset code later arrives from that sender, the agent may act on the retained instruction and disclose the code through an attacker-controlled channel.

The researchers also described “asymmetric messaging,” where a human operator sees a benign HTML email. At the same time, the AI system processes a different plain-text version containing injected instructions.

Similarly, poisoned community comments or attacker-controlled pages indexed by a Retrieval-Augmented Generation (RAG) knowledge base can be viewed as trusted company content.

Defensive Priorities

Organizations deploying AI support agents should treat them as privileged applications, not simple chat interfaces. Key protective measures include:

• Bind every sensitive action to server-side, normalized account identities and fresh authorization checks.
• Never trust email display headers, caller ID, quoted thread content, or model memory as proof of identity.
• Require step-up verification for profile changes, refunds, financial actions, and data disclosure.
• Isolate OTPs and third-party security emails from autonomous agent workflows.
• Restrict tool permissions, validate tool inputs, and log every agent-initiated action.
• Separate official knowledge-base content from user-generated material before RAG indexing.
• Test agents against indirect prompt injection, MIME-content discrepancies, parser differentials, and cross-channel authentication failures.

Human approval alone is insufficient when the reviewer and AI agent may see different information or when the agent possesses excessive authority.

Keep your SOC up to date on active malware & phishing within 24h of their emergence. Try ANYRUN to prevent incidents with early detection.