Dos esfuerzos independientes de investigación de seguridad, publicados esta semana, revelan que **OpenClaw**, un agente de IA autoalojado ampliamente adoptado, puede ser coaccionado para ejecutar código malicioso o divulgar información sensible a través de entradas de apariencia ordinaria. **Imperva** demostró cómo las instrucciones ocultas incrustadas en contactos compartidos, vCards y pines de ubicación podían ser ejecutadas por el agente sin el conocimiento de la víctima. Simultáneamente, **Varonis** logró engañar a un agente de prueba, precargado con datos empresariales sintéticos, para que reenviara claves de AWS simuladas y una exportación de clientes falsa a través de un único correo electrónico simple. Mientras que la falla descubierta por **Imperva** ha sido abordada en la versión 2026.4.23 de **OpenClaw**, la vulnerabilidad de phishing de **Varonis** resalta un desafío arquitectónico más profundo que no puede resolverse con un simple parche. Ambos ataques subrayan una debilidad fundamental: la confianza inherente del agente en los datos entrantes, que, combinada con sus privilegios de acceso, crea un potente vector de ataque. ## Comandos Ocultos en un Contacto Compartido El investigador de **Imperva**, **Yohann Sillam**, profundizó en cómo **OpenClaw** procesa los datos de mensajería para su modelo de lenguaje grande (LLM) subyacente. El problema central radica en el manejo interno de los objetos de mensaje por parte del agente. Cuando **OpenClaw** transmite contactos compartidos, vCards o ubicaciones al LLM, aplana estos objetos directamente en el texto del prompt. Crucialmente, a diferencia del contenido obtenido de la web, que se marca como no confiable, los objetos de mensaje carecen de este límite crítico. Solo se envían campos específicos al modelo, una debilidad explotada por el ataque. Por ejemplo, un contacto compartido solo envía el campo de nombre, serializado como `<contact: name, number>`. Los corchetes angulares son permisibles en los nombres, lo que hace imposible que el modelo distinga entre un nombre legítimo y una instrucción inyectada. Además, el nombre del contacto se trunca en pantalla tanto en **WhatsApp** como en la aplicación receptora, ocultando efectivamente el payload malicioso de la víctima. Esta técnica también resulta efectiva a través del campo de nombre completo de una vCard, nativamente compatible con **WhatsApp**, y a través de la etiqueta de un pin de ubicación compartido. En las pruebas de **Imperva** contra **Google Gemini 3.1 Pro** (versión preliminar), el texto oculto instruyó con éxito al agente para descargar y ejecutar un script desde un servidor controlado por el investigador. Si bien los intentos de incrustar instrucciones en imágenes simples fallaron (probablemente debido a que los modelos fueron entrenados contra ataques tan comunes), la ruta de objetos de mensaje tuvo éxito debido a su novedad.  **Imperva** advierte que con la memoria de **OpenClaw** habilitada por defecto, una sola pieza de contenido ampliamente compartido que contenga una instrucción oculta podría comprometer silenciosamente a los agentes no aislados que la ingieren. Tras la divulgación de **Imperva**, **OpenClaw** lanzó una corrección en la versión 2026.4.23, que ahora enruta los nombres de contacto, los campos de vCard y las etiquetas de ubicación a través de un canal de metadatos separado y no confiable. **Imperva** notó patrones de aplanamiento similares en otros asistentes personales de IA, lo que indica un problema más amplio en la industria. ## Un Correo Electrónico Normal es Suficiente **Varonis Threat Labs** abordó **OpenClaw** desde una perspectiva de ingeniería social. Liderado por **Itay Yashar**, su equipo desarrolló un agente llamado **Pinchy** en la plataforma, vinculándolo a una bandeja de entrada de **Gmail** llena de datos empresariales sintéticos realistas y secretos simulados. Luego sometieron a **Pinchy** a cuatro simulaciones de phishing utilizando **Google Gemini 3.1 Pro** y **OpenAI Codex GPT-5.4**. **Varonis** distingue entre la inyección de prompts, que oculta instrucciones dentro de los datos, y lo que ellos denominan 'agent phishing': una solicitud creíble entregada a través de un canal normal que tiene éxito porque el agente actúa sin una verificación adecuada del remitente. El agente falló en ambas pruebas de exfiltración. En el primer escenario, un mensaje que pretendía ser de un líder de equipo llamado Dan, enviado desde una dirección externa de **Gmail**, solicitó acceso de staging durante un incidente de producción simulado. **Pinchy** localizó las credenciales y reenvió claves de acceso simuladas de AWS IAM, cadenas de conexión de bases de datos y credenciales SSH en texto plano.  El segundo pretexto fue una solicitud más suave para la exportación semanal de clientes, supuestamente para una presentación de QBR. El agente luego envió un conjunto de datos sintético de 247 clientes empresariales, incluidos contactos y valores de contrato. Ambas fallas ocurrieron a pesar de un perfil estricto configurado para verificar primero a los remitentes; la urgencia anuló la regla en un caso, y la rutina en el otro. El agente se desempeñó mejor contra amenazas técnicas que contra sociales. Interactuó con una página de phishing de tarjetas de regalo, pero retuvo las credenciales reales y finalmente la marcó; el perfil estricto bloqueó la página por completo. Cuando se le presentó una pantalla de consentimiento de **OAuth** maliciosa disfrazada de aplicación de hojas de tiempo, inspeccionó el objetivo de redirección, lo consideró sospechoso y se detuvo antes de otorgar acceso. Esto resalta la conclusión clave de **Varonis**: el agente a menudo es más hábil que los humanos para identificar URL maliciosas y portales de inicio de sesión falsos, pero significativamente peor en el juicio social que impulsa a un humano a detenerse cuando un colega hace una solicitud inusual de credenciales. El impulso inherente del agente de ser útil emerge como una superficie de ataque crítica.  **Varonis** señaló que **OpenAI Codex GPT-5.4** mostró más precaución que **Gemini 3.1 Pro** con respecto a ingresar o enviar datos a sitios externos sin confirmación, aunque ambos sucumbieron a los pretextos sociales. ## El Punto Débil Detrás de Ambos Ataques **Varonis** mapea ambos vectores de ataque al concepto de **Simon Willison** de la 'trifecta letal': un agente capaz de leer datos privados, ingerir contenido no confiable y exfiltrar datos. **OpenClaw** posee las tres capacidades, lo que explica por qué un contacto envenenado y un correo electrónico aparentemente benigno pueden conducir al mismo compromiso. Este problema de límite de confianza se extiende más allá de los problemas de prompt, manifestándose en la base de código de **OpenClaw**. Un análisis separado de **InfoSec Write-ups** convirtió avisos anteriores de **OpenClaw** en reglas de análisis estático, descubriendo posteriormente cinco fallas adicionales en sus extensiones de canales de **Slack**, **Discord**, **Matrix**, **Zalo** y **Microsoft Teams**. Las cinco vulnerabilidades compartieron una raíz común: el código de inicio resolvió la lista de permitidos de cada canal por nombre de visualización mutable en lugar de un ID estable. Esto permitió a un atacante renombrarse para coincidir con un usuario permitido, obteniendo así acceso no autorizado y control sobre el agente. **OpenClaw** ha parcheado desde entonces estos problemas. **OpenClaw** viene con un acceso extenso a archivos, shells y más de veinte plataformas de mensajería, y ha sido objeto de advertencias constantes de inyección de prompts y exfiltración de datos desde su lanzamiento a finales del año pasado. La **autoridad de protección de datos holandesa**, la **Autoriteit Persoonsgegevens**, ha adoptado una postura firme, desaconsejando a los usuarios y organizaciones que ejecuten **OpenClaw** en sistemas que contengan datos sensibles, citando riesgos significativos de filtración de datos y robo de cuentas. ## Qué Hacer al Respecto Las organizaciones que ejecutan **OpenClaw** deben actualizar inmediatamente a la versión 2026.4.23 o posterior para aplicar la corrección de objetos de mensaje. Más allá del parcheo, las defensas restantes son arquitectónicas, no meramente de redacción de prompts. **Varonis** describe cuatro controles críticos: 1. **Trate el archivo de instrucciones del agente como una política aplicada y controlada por versión, no como una sugerencia.** 2. **Implemente una puerta de enlace para el correo saliente:** prohíba los envíos por primera vez a direcciones desconocidas sin aprobación explícita para evitar que un agente secuestrado retransmita intentos de phishing desde una cuenta confiable. 3. **El acceso al conector debe rastrear el nivel de confianza de la entidad conectada.** 4. **Aísle el agente (sandbox).**