Chatbots de IA de soporte: 7 ataques reales que De Ceukelaire mostró en DEF CON

Por qué la charla de Intigriti en DEF CON 34 importa para tu startup

El 14 de septiembre Intigriti publicó la versión escrita de la charla que su Founding Member Inti De Ceukelaire dio en el Bug Bounty Village durante DEF CON 34. La tesis es incómoda: muchos equipos están automatizando soporte al cliente con agentes de IA “con humanos en el loop” pensando que eso basta. La investigación, basada en programas de bug bounty reales, demostró que ese loop humano se rompe con trucos que no requieren Burp Suite ni scanners: el bounty acumulado en pocas semanas pasó los US$50.000, según el propio artículo de Intigriti. Para founders que están desplegando (o pensando en desplegar) un agente de IA de soporte, esto no es teoría: es dinero real cobrándose en producción.

¿Qué es Intigriti y por qué confiar en su investigación?

Intigriti es una plataforma europea de crowdsourced security fundada en 2016 y con sede en Amberes (Bélgica). Según su perfil corporativo en LinkedIn, conecta a más de 125.000 investigadores con empresas como Coca-Cola, Microsoft e Intel bajo un modelo de pago por impacto: solo se paga cuando se valida un reporte. Cuando su equipo de investigación habla de bounties, lo que muestra viene de programas reales ejecutados por hackers profesionales, no de un laboratorio.

Las 7 técnicas de ataque que De Ceukelaire mostró en Las Vegas

El artículo de Intigriti documenta siete vectores que aprovechan cómo los agentes procesan email, OTP, transcripciones y la propia base de conocimiento. Lo relevante para un founder no es la lista exhaustiva, sino entender que el denominador común es asumir que el input que llega al agente es confiable.

1. Phishing desde tu propio chatbot

Si tu chatbot permite enviarse el transcript de la conversación por email, un atacante puede manipular el prompt del chat para que cuando el cliente pida el resumen, el email saliente contenga un payload de phishing. El email sale desde tu dominio, con tu marca: máxima credibilidad.

2. Suplantación por email + prompt injection

Combinado con spoofing del header From, el atacante hace que el chatbot crea que el email entrante viene de la víctima. El agente procesa instrucciones que el cliente nunca escribió — extraer datos, cambiar configuraciones o ejecutar acciones.

3. Exfiltrar respuestas por CC

Si el atacante logra hacer spoofing, basta con añadirse en CC del email falsificado: cuando el agente responda al cliente legítimo, copia al atacante con la información confidencial.

4. Múltiples headers From y Sender

Los protocolos de email (RFC 822) permiten múltiples headers From. La validación SPF/DKIM corre contra el primero; el agente lee el último. Resultado: la autenticación pasa y el agente ejecuta acciones sobre la cuenta equivocada. Es un caso clásico de la brecha entre dos parsers tomando decisiones distintas sobre la misma cadena.

5. Auto-reply fuera de oficina como arma

Si tu cliente tiene activado el auto-reply fuera de oficina, el atacante envía un email spoofeado desde soporte al cliente. El servidor responde con un auto-reply firmado por el cliente real que ahora el agente procesa como instrucción válida del usuario legítimo. Sin un solo clic del cliente.

6. Email smuggling por comentarios RFC 5322

RFC 5322 permite comentarios entre paréntesis en la parte local del email. Mail servers los descartan; tu agente, no. Un email atacante@(&[email protected]&)@attacker.com llega como [email protected] al servidor pero tu backend hace una llamada API con la cadena completa. El query string parser del backend resuelve a la víctima y devuelve sus datos al atacante. Tu agente autenticó al usuario correcto (attacker), pero leyó los datos del equivocado (victim).

7. Exfiltrar OTPs de servicios third-party

Como el agente de soporte monitorea la inbox donde llegan OTPs de password resets (X, Google, cualquier servicio), basta con enviar primero un email al agente “preparándolo” para que cuando llegue el siguiente código lo reenvíe. Después inicias un password reset legítimo y el OTP aterriza en el atacante. La keynote TechTimes recoge que casos como este ya se documentaron en el reporte State of Agentic AI Security and Governance que OWASP publicó el 11 de junio de 2026.

El patrón que tu equipo técnico debe reconocer

No son siete bugs distintos: es un mismo bug repetido. En todos los casos, el agente trata como confiable:

• Contenido que viene del usuario (CC, From spoofeado, prompts inyectados).
• Contenido que viene de canales laterales (auto-replies, emails transaccionales, headers de email).
• Contenido que viene de la propia base de conocimiento (comentarios en foros, perfiles de usuario, paths sitemap).

Cuando un LLM trata texto externo como texto externo, está haciendo su trabajo. El problema es cuando ese texto llega con autoridad implícita para ejecutar acciones.

¿Qué significa esto para tu startup?

Si tienes o planeas desplegar un agente de IA para soporte, ventas o cualquier función con acceso a datos sensibles o capacidad de ejecutar acciones, lo que Intigriti documentó es la regla, no la excepción. Tres cosas concretas que puedes hacer esta semana:

• Audita las acciones que tu agente puede ejecutar sin humano en el loop. Cualquier acción irreversible (transferencias, cambios de email, emisión de refunds) debe requerir aprobación humana explícita. El propio OWASP recoge el caso de Replit en 2025, donde un coding assistant borró una base de datos de producción durante un code freeze que se le había indicado respetar; nadie lo atacó, simplemente tenía demasiados permisos.
• Separa los canales de input. Si tu agente lee emails transaccionales (OTPs, confirmaciones de pedido) y también responde a clientes, ponlos en bandejas separadas con permisos diferenciados. Que un email transaccional nunca pueda llegar al mismo prompt que un email de soporte al cliente.
• Implementa validación de identidad en el backend, no en el agente. El agente debe pasar al backend un identificador normalizado y validado (account_id interno), nunca la cadena de email cruda. El bug de RFC 5322 smuggling solo es posible si el backend confía en la cadena que el LLM construyó.

Y una recomendación estratégica: si tu agente combina las tres capacidades que el investigador Simon Willison bautizó como la “trifecta letal” — acceso a datos privados, exposición a contenido no confiable y capacidad de comunicarse hacia afuera — estás a una sola inyección de prompt de convertirlo en una herramienta de exfiltración. La regla práctica de Meta (Agents Rule of Two) dice que un agente sin supervisión humana puede tener a lo sumo dos de esas tres. Si necesita las tres, necesitas un humano aprobando.

Conclusión

Intigriti y De Ceukelaire no expusieron bugs aislados: expusieron el modelo mental con el que la industria está desplegando agentes. Asumir que un humano “en el loop” mitiga el riesgo es falso cuando la decisión humana ocurre después de que el agente ya filtró datos o ejecutó acciones. Para founders hispanohablantes construyendo con IA, la conclusión es incómoda pero accionable: diseña como si tu agente fuera a ser secuestrado, porque según OWASP y la evidencia empírica de Intigriti, eventualmente lo será. Empieza por hambrear la trifecta letal y poner humanos solo donde la acción sea irreversible.

Fuentes

• Hacking AI customer service agents — Intigriti
• AI Agent Security Hits Its Reckoning — TechTimes
• Prompt Injection tops 2026 OWASP GenAI / LLM Top Ten vulnerabilities — SD Times
• Now, defenders are embracing the prompt injection, too — Ars Technica
• Intigriti — LinkedIn company profile