La nueva forma en que los hackers engañan a los asistentes financieros basados en IA
por
Última actualización:
Tiempo de lectura: 7 minutos
Puntos clave
- Los hackers están incorporando activamente cargas útiles de inyección indirecta de comandos en documentos habituales para secuestrar asistentes financieros basados en IA.
- A diferencia del fraude tradicional, que engaña a las personas, este ataque se dirige a la inteligencia artificial automatizada, que ejecuta órdenes al instante sin sospechar nada.
- Los agentes de IA capaces de realizar transferencias de dinero, iniciar flujos de trabajo o acceder a datos de clientes sujetos a regulación son los objetivos más valiosos para los atacantes.
- Las alertas del sistema por sí solas no bastan para garantizar la seguridad de un agente, por lo que resultan esenciales la aplicación estricta del principio de «privilegio mínimo» y las aprobaciones humanas obligatorias.
- Dado que el correo electrónico es el principal medio de distribución de estas cargas maliciosas, es necesario aplicar estrictamente el protocolo DMARC para autenticar los mensajes antes de que una IA los procese.
Unos investigadores de seguridad que analizaban contenidos en el entorno real han descubierto recientemente algo alarmante. Encontraron instrucciones ocultas escritas no para un ser humano, sino para cualquier agente de IA que leyera el texto. Una de ellas era una carga útil totalmente maliciosa, diseñada específicamente para hacer que un asistente de IA con capacidad de pago ejecutara una transacción fija de 5.000 dólares. No se trataba de una demostración controlada en laboratorio, sino de una carga útil real encontrada en el entorno real.
Durante los últimos diez años, las entidades financieras han dedicado enormes recursos a formar a sus empleados para que no actúen ante correos electrónicos convincentes. Ahora, muchas de esas mismas entidades han conectado asistentes de inteligencia artificial a esas mismas bandejas de entrada. Estos asistentes lo leen todo, no cuestionan nada y, a menudo, operan con los permisos de los empleados que los utilizan.
Esta técnica se denomina «inyección indirecta de comandos». Supone un cambio radical en el funcionamiento del fraude financiero. A continuación se ofrece un desglose de cómo funciona el ataque, cuáles son los puntos vulnerables reales de los bancos, qué han demostrado realmente los investigadores en 2026 y los controles arquitectónicos necesarios para detenerlo.
¿Qué es la inyección inmediata?
La inyección de comandos se produce cuando un atacante manipula un sistema de IA para que ejecute comandos no deseados. La inyección directa se produce cuando un usuario escribe instrucciones maliciosas directamente en la ventana de chat. La inyección indirecta de comandos es mucho más peligrosa. Se produce cuando las instrucciones se ocultan dentro de contenido externo que el asistente lee automáticamente, como un correo electrónico recibido, una factura adjunta o una página web.
La razón principal por la que esto funciona es sencilla: los sistemas de IA actuales no distinguen de forma fiable entre instrucciones y datos. Cada documento que procesa un asistente se trata como una posible entrada, lo que significa que cualquier archivo externo puede convertirse en un vehículo para un ataque.
Por qué los asistentes financieros basados en IA son un objetivo de gran valor
Mayur Sewani, investigador sénior de seguridad de Forcepoint, describe el problema a la perfección: el impacto es proporcional al nivel de privilegios. Un asistente de IA que solo resume las notas de las reuniones supone un riesgo bajo. Un asistente capaz de enviar correos electrónicos, activar un flujo de trabajo o realizar transferencias de dinero es un objetivo crítico y de gran impacto.
Los asistentes que se están implantando actualmente en todo el sector financiero pertenecen, cada vez más, a este segundo tipo. Recuperan registros de clientes, analizan documentos de cumplimiento normativo, inician flujos de trabajo internos y, en algunas implantaciones, interactúan directamente con los sistemas de pago.
En el ámbito del comercio minorista, una instrucción inyectada podría limitarse a filtrar un documento. En un banco, esa misma instrucción inyectada puede transferir dinero, revelar datos de clientes sujetos a una estricta regulación o alterar una decisión relacionada con el cumplimiento de la normativa «Conoce a tu cliente» (KYC).
Cuándo una entidad financiera está realmente expuesta
El modelo de amenazas cambia por completo cuando se concede a un agente de IA acceso a los sistemas bancarios. La tabla siguiente detalla las áreas operativas específicas en las que las entidades se encuentran expuestas en la actualidad.
| Área operativa | Vector de ataque | Posible impacto en el negocio |
|---|---|---|
| Operaciones de pago | Un asistente con facultades de aprobación o de puesta en marcha lee un documento de instrucciones recibido que contiene texto oculto. | Se engaña al agente para que transfiera fondos a la cuenta de un atacante utilizando los permisos del operador humano. |
| Incorporación de clientes y KYC | A un asistente encargado de resumir los documentos presentados se le introduce texto oculto que le ordena suprimir o alterar una conclusión crítica sobre el riesgo. | Un cliente de alto riesgo elude los controles de cumplimiento. Ya se han documentado en el mundo real cargas útiles diseñadas para la supresión de contenidos. |
| Atención al cliente | Se recibe una instrucción introducida de forma indebida a través de un ticket de asistencia enviado por un cliente o de un mensaje de chat. | El mensaje malicioso ejecuta comandos utilizando los privilegios elevados de servicio técnico concedidos al asistente de IA. |
| Búsqueda interna de conocimientos | Los agentes con acceso a documentos de operaciones, expedientes crediticios o documentos del consejo de administración abren un enlace o un documento malicioso. | La IA extrae material confidencial al que tiene acceso y lo envía a un servidor controlado por el atacante. |
| Correspondencia con los proveedores | Las cargas útiles ocultas se incrustan en los correos electrónicos entrantes procedentes de terceros comprometidos. | Los atacantes se aprovechan del canal de entrada de mayor nivel de confianza para enviar instrucciones directamente a los agentes programados para procesar las facturas de los proveedores. |
Lo que los investigadores demostraron realmente en 2026
Esta amenaza ya no es meramente teórica. Los investigadores en materia de seguridad han documentado exhaustivamente cómo estas vulnerabilidades se manifestaron en entornos empresariales reales en 2026.
Las diez cargas útiles de Forcepoint en circulación (abril de 2026)
El 23 de abril de 2026, los investigadores de Forcepoint publicaron sus conclusiones sobre diez cargas útiles de inyección indirecta detectadas en el entorno real. Estas cargas útiles abarcaban la supresión de contenido, el secuestro de atribución, la ejecución de comandos Unix contra herramientas de desarrollo y el robo de claves de API. Lo más preocupante para los bancos es que la investigación detallaba una carga útil de fraude en pagos dirigida a agentes de IA con capacidades de pago integradas. La carga útil contenía instrucciones incrustadas para activar una transacción fija de 5.000 dólares a través de PayPal. Sewani calificó esta carga útil como un arma diseñada para su ejecución inmediata, y no como una inofensiva prueba de investigación.
El ataque «Reprompt» contra Microsoft Copilot (enero de 2026)
El 15 de enero de 2026, Varonis detalló el ataque «Reprompt». Se trataba de una cadena de exfiltración de datos con un solo clic dirigida a Microsoft Copilot. El ataque utilizaba un parámetro de URL para inyectar instrucciones. Se ordenaba al asistente que repitiera acciones para eludir las medidas de seguridad, estableciendo un intercambio continuo de mensajes con un servidor controlado por el atacante con el fin de exfiltrar datos. El ataque se llevó a cabo a través de un enlace de Copilot de apariencia legítima enviado por correo electrónico, que solo requería un clic por parte de la víctima. Microsoft corrigió rápidamente la vulnerabilidad y, según se informó, la versión empresarial de Microsoft 365 Copilot no se vio afectada, pero el mecanismo demostró que un agente revelará sin reparos cualquier contexto interno al que pueda acceder si se le engaña.
La tendencia general
No se trata de un problema exclusivo de un único proveedor. Se han demostrado con éxito ataques de inyección contra herramientas de codificación basadas en agentes a través de comentarios en el código fuente, y existen numerosos casos bien documentados de elusión de las medidas de seguridad en varios modelos importantes.
Se trata de un caso de suplantación de identidad en el correo electrónico empresarial, pero con un objetivo diferente
El patrón de un ataque de inyección indirecta es funcionalmente idéntico al del «Business Email Compromise» (BEC). Se recibe una instrucción fraudulenta que parece totalmente legítima y alguien la lleva a cabo. La diferencia fundamental es que ese «alguien» es ahora un programa informático. La IA no tiene dudas, ni la corazonada de que algo va mal, ni el instinto de coger el teléfono y verificar una solicitud extraña con el director financiero.
Afortunadamente, los controles que las instituciones ya aplican para las transferencias BEC abordan directamente este nuevo problema. La verificación fuera de banda, la aprobación por parte de varias personas para los pagos o los cambios de beneficiario, y los límites máximos estrictos para cualquier acción automatizada individual siguen siendo vuestras mejores defensas. Un agente de IA debe operar dentro de esos controles existentes, nunca fuera de ellos.
Controles: Reducción del radio de explosión de un agente de IA
Los arquitectos de seguridad y los equipos de gestión de riesgos deben establecer controles estructurales en torno a los agentes de IA. No se puede confiar únicamente en las indicaciones del sistema para garantizar la seguridad de una plataforma financiera.
| Principio de control | Aplicación práctica | Objetivo de seguridad |
|---|---|---|
| Privilegio mínimo | Limita estrictamente las facultades de pago, envío y aprobación. | Asegúrate de que la mayoría de los asistentes solo tengan permisos de lectura, limitando así los daños que puedan causar en caso de que se vea comprometida su seguridad. |
| Intervención humana | Exigir la aprobación humana para las acciones que tengan consecuencias importantes. | Mantén el control de seguridad en la propia acción. Un pago financiero siempre debe requerir que una persona haga clic para aprobarlo. |
| «Zero Trust» para contenidos | Trata todos los documentos recibidos (PDF, correos electrónicos, documentos) como datos introducidos por el usuario que no son fiables. | Evita que el agente ejecute texto sin procesar extraído de archivos externos sin validarlo previamente. |
| Registro de API y herramientas | Mantener registros de auditoría rigurosos que reflejen exactamente lo que el agente ha leído y lo que ha ejecutado. | Garantizar una rápida visibilidad forense durante una investigación de respuesta ante incidentes. |
| Filtrado estricto de salidas | Bloquea las conexiones salientes hacia direcciones IP desconocidas o que no sean de confianza. | Detén ataques como la cadena «Reprompt», que dependen de llegar a un servidor controlado por el atacante para sustraer datos. |
| Flujos de trabajo unificados | Integra agentes de IA en tus marcos actuales de control de pagos. | Evitar la creación de procesos de aprobación paralelos y no verificados que eludan los controles de seguridad existentes. |
Hay que ser realista en cuanto a la detección. Filtrar los documentos entrantes en busca de frases clave conocidas que activan la inyección de comandos no es más que un pequeño obstáculo. Los atacantes simplemente reformularán sus cargas maliciosas.
No puedes salir de esta situación con simples indicaciones
Mientras un agente de IA pueda ser persuadido mediante texto, los únicos controles duraderos son los estructurales. Hay que restringir físicamente lo que el agente puede hacer, a qué sistemas puede acceder y qué acciones requieren estrictamente la intervención de un humano. Unas indicaciones del sistema más eficaces y las medidas de protección de los proveedores sin duda aumentan el coste de un ataque, pero no eliminan ese tipo de vulnerabilidad. Para una entidad financiera regulada, esa distinción supone la diferencia entre un control que se puede demostrar ante un auditor y otro del que solo se puede suponer que funciona.
Lo que indican los supervisores
Las autoridades reguladoras están prestando mucha atención a este cambio. Las directrices de la FINRA sobre temas clave en materia de inteligencia artificial para 2026 y los informes de supervisión señalaron específicamente la IA autónoma como una categoría de riesgo de supervisión diferenciada. Dado que estos sistemas realizan acciones autónomas en lugar de limitarse a generar texto, las empresas deben mantener registros de auditoría completos e implementar controles humanos antes de la ejecución. La FINRA también destacó los riesgos de la IA en la sombra y la necesidad de tratar las plataformas de IA de terceros como proveedores de alto riesgo (tal y como se detalla en la cobertura secundaria de Smarsh).
La OCC también ha indicado que está a punto de publicarse una guía exhaustiva sobre la gobernanza de los modelos de IA para los bancos. Además, la FS-ISAC ha publicado una serie de libros blancos sobre los riesgos de la IA en el sector financiero, que abarcan la taxonomía de la IA adversaria y la evaluación de proveedores. Cabe señalar que dichos documentos se publicaron en febrero de 2024, antes de la «ola agentiva», pero siguen siendo útiles para adquirir una base básica sobre el sector.
Los supervisores y los arquitectos de seguridad, en el fondo, piden exactamente lo mismo: una supervisión humana demostrable de las acciones de la IA que tengan consecuencias importantes. Esa armonización normativa es el argumento interno más sólido con el que cuenta un responsable de seguridad para conseguir financiación con el fin de implantar estos controles.
El papel de la autenticación del correo electrónico
Es importante dejar claro lo que la autenticación de correo electrónico no puede hacer. DMARC con el parámetro p=reject no impide la inyección de mensajes; no inspecciona el contenido de los mensajes y no limita lo que un agente de IA está autorizado a hacer.
Sin embargo, las cargas útiles de inyección con más probabilidades de tener éxito frente al asistente de IA de un banco son aquellas que llegan aparentando proceder del director financiero, de un banco corresponsal o de un procesador de pagos de confianza. El correo electrónico es la principal vía por la que el contenido no fiable llega a estos sistemas de IA. La cadena «Reprompt» revelada se transmitió a través de un enlace enviado por correo electrónico. Cuando un agente de IA procesa el correo sin supervisión humana alguna, la autenticidad del remitente se convierte en la última señal de confianza del proceso.
El sector de los servicios financieros presenta unas de las tasas de adopción de DMARC más altas de todos los sectores, pero, lamentablemente, también cuenta con uno de los niveles de aplicación más bajos. Si estás integrando la inteligencia artificial en una bandeja de entrada, aplicar una autenticación estricta del correo electrónico ya no es opcional. Para obtener más información sobre cómo proteger este vector, consulta nuestro estudio sobre el phishing en los servicios financieros y el protocolo DMARC en las instituciones financieras.
Conclusión
Durante la última década, el eslabón más débil en la seguridad del correo electrónico financiero era el propio empleado que hacía clic en un enlace malicioso. Ahora, las instituciones han cedido esa misma bandeja de entrada a un software que lo lee todo, no cuestiona nada y cuenta con permisos reales del sistema. Las primeras cargas maliciosas diseñadas específicamente para aprovechar esos agentes automatizados ya están en circulación.
La solución requiere un enfoque por capas. Debes limitar lo que los agentes de IA pueden hacer físicamente, mantener a las personas informadas en las acciones de mayor importancia, integrar a estos agentes en tus controles de pago existentes y verificar rigurosamente cualquier dato que les llegue.
Comprueba el estado de seguridad de tu dominio con nuestro verificador de registros DMARC o visita nuestra página de soluciones para servicios financieros para obtener más información sobre cómo proteger tus canales de entrada.
Preguntas frecuentes
¿Qué es la inyección inmediata en términos sencillos?
Se trata de un ciberataque en el que un pirata informático oculta instrucciones secretas dentro de un documento o un correo electrónico. Cuando un asistente de IA lee ese archivo, ejecuta sin saberlo los comandos ocultos.
¿Puede una orden de voz hacer que un asistente de IA realice una transferencia de dinero?
Sí. Si a un agente de IA se le ha concedido acceso a los sistemas de pago y carece de controles de aprobación con intervención humana, una instrucción oculta puede obligarle a realizar transferencias no autorizadas.
¿Se ha utilizado la inyección de comandos en ataques reales?
Sí. En abril de 2026, los investigadores documentaron diez cargas útiles distintas de inyección indirecta de comandos en entornos reales, incluida una diseñada específicamente para realizar una transacción de 5.000 dólares a través de PayPal.
¿En qué se diferencia el «prompt injection» del «business email compromise»?
El patrón del ataque es similar, pero la víctima es otra. En lugar de engañar a un empleado humano para que realice una transferencia bancaria, el atacante engaña a un agente de software automatizado basado en IA que ejecuta la solicitud al instante.
¿Qué controles debería establecer un banco en torno a un agente de IA?
Los bancos deben aplicar el principio del privilegio mínimo, exigir la aprobación humana para todas las acciones que tengan consecuencias importantes, implementar un filtrado estricto de las salidas de la red y registrar cada llamada a la API que realice el agente.
¿DMARC o la autenticación del correo electrónico impiden la inyección de comandos?
No, DMARC no puede inspeccionar el contenido de un correo electrónico en busca de mensajes ocultos. Sin embargo, impide desde el principio que los correos electrónicos falsificados lleguen a la IA, eliminando así una vía importante de entrega para el ataque.
Especialista en contenidos en PowerDMARC
Milena es una hábil escritora y creadora de contenidos con más de 7 años de experiencia en la elaboración de contenidos atractivos sobre TI, ciberseguridad, eventos virtuales y mucho más. Tiene un historial probado de entrega de trabajos de alta calidad para revistas internacionales y se ha graduado en prestigiosas instituciones como la New York University Abu Dhabi, UWC China y el College of Europe.
Últimos mensajes de Milena Baghdasaryan (ver todos)
- La nueva forma en que los hackers engañan a los asistentes financieros basados en IA - 7 de septiembre de 2026
- Prácticas recomendadas de seguridad del DNS: una lista de comprobación completa para reforzar la seguridad - 7 de septiembre de 2026
- SPF dinámico, SPF automático y SPF alojado: ¿cuál de ellos corrige realmente tu registro SPF? - 25 de agosto de 2026
