La trampa de la confianza en los agentes autónomos y qué hacer antes de que sea tarde

Dos equipos de investigación han mostrado esta semana que los agentes autónomos autoalojados pueden ser comprometidos con técnicas que parecen inofensivas: Imperva demostró que OpenClaw ejecutaba instrucciones escondidas en contactos compartidos, vCards y pines de ubicación, y Varonis probó que un agente bien configurado puede ser persuadido por correos creíbles para filtrar claves y datos sensibles. El vector no fue una explotación críptica del modelo, sino la manera en que el agente confía en la información que le llega y la entrega al LLM sin marcarla como no fiable.

El hallazgo técnico de Imperva revela un fallo en la "plomería" de OpenClaw: al serializar objetos de mensajería el agente inserta campos como el nombre de contacto o la etiqueta de ubicación directamente en el prompt, usando un formato que permite incluir caracteres legales (como los signos de menor/ mayor) para camuflar instrucciones. El resultado práctico fue que, en sus pruebas con Gemini 3.1 Pro, el modelo descargó y ejecutó un script alojado por los investigadores. OpenClaw corrigió ese comportamiento en la versión 2026.4.23 moviendo esos campos a un canal de metadatos marcado como no fiable; si se usa la herramienta, actualizar a esa versión es la acción mínima e inmediata. Para entender mejores prácticas sobre inseguridades de LLM y agentes conviene revisar el trabajo comunitario en seguridad de modelos, por ejemplo en el proyecto OWASP de seguridad LLM https://owasp.org/www-project-llm-security/.

Varonis, por su parte, abordó el problema por la vía social: construyó un agente llamado Pinchy, lo alimentó con un buzón simulado lleno de datos empresariales y ejecutó campañas de phishing dirigidas al agente en Gemini 3.1 Pro y OpenAI Codex GPT-5.4. Las pruebas mostraron que un correo aparentemente legítimo —urgente o rutinario— bastaba para que el agente, pese a tener normas para verificar remitentes, reenviara claves AWS y exportaciones de clientes. La conclusión es clara: los agentes son excelentes analizando URLs y portales técnicos sospechosos, pero son mucho más frágiles frente a pretextos sociales que explotan su inclinación a ayudar. Varonis plantea controles arquitectónicos: políticas como código aplicadas por el sistema, puertas de salida para correos salientes hacia direcciones nuevas, control del nivel de confianza por conector y bloqueo de acciones de alto riesgo hasta confirmación humana.

Estos incidentes no sólo exponen bugs puntuales; muestran una tensión fundamental en el diseño de agentes: para que sean útiles deben leer datos privados y, a la vez, decidir con autonomía. Simon Willison describió esto como una "trifecta letal": lectura de datos privados, ingestión de contenido no confiable y capacidad de enviar datos fuera. OpenClaw tiene las tres capacidades, y el vector de ataque puede venir tanto de un archivo mal formado como de un correo perfectamente escrito por un atacante. Esa clase de riesgo trasciende parches y exige cambios de arquitectura y proceso.

La superficie de ataque también se reflejó en errores de implementación reportados por analistas: extensiones para Slack, Discord, Matrix, Zalo y Teams resolvían listas blancas por nombres cambiables en vez de identificadores estables, permitiendo que un atacante que se renombrara suplantase a una cuenta permitida. OpenClaw ha publicado arreglos para esos casos, pero la lección es sistémica: las decisiones sobre identidad y confianza deben basarse en identificadores inmutables y auditablemente verificables.

Desde la regulación, el impacto ya llegó: la autoridad holandesa de protección de datos (Autoriteit Persoonsgegevens) recomendó no ejecutar OpenClaw en sistemas que contengan datos sensibles, por riesgos de fuga y toma de control de cuentas. Ese pronunciamiento subraya que el riesgo no es solo técnico sino también legal y de cumplimiento; las organizaciones deben evaluar agentes como puntos de posible violación de datos y responsabilidades de controlador. Para más información sobre marcos regulatorios y privacidad, la web de la Autoriteit Persoonsgegevens puede servir como referencia institucional https://autoriteitpersoonsgegevens.nl/en.

¿Qué deben hacer los equipos de seguridad y los responsables de producto ahora mismo? Primero, aplicar parches y mitigaciones publicadas (por ejemplo la actualización 2026.4.23 de OpenClaw). Segundo, tratar al agente como un empleado junior con acceso a sistemas: imponer políticas como código que el agente no pueda sobrepasar, exigir confirmación humana para acciones críticas y registrar y revisar exhaustivamente cualquier actividad de salida. Tercero, segmentar permisos por conector: un canal de correo externo no debe implicar acceso libre al CRM ni a secretos mientras no se verifique la confianza del origen. Cuarto, limitar memoria por defecto y considerar mecanismos de "ephemeral context" para minimizar rastros persistentes de instrucciones maliciosas. Además, poner puertas de salida que impidan envíos a direcciones externas desconocidas sin autorización y aplicar controles de egress en red para bloquear descargas ejecutables no aprobadas.

También hacen falta controles organizativos: políticas de threat modeling para agentes, formación específica sobre ingeniería social dirigida contra agentes (no solo contra humanos), revisiones de auditoría que correlacionen acciones del agente con triggers humanos, y reglas de detección en SIEM/EDR que busquen patrones de exfiltración vía integraciones. La adopción de listas blancas basadas en IDs inmutables y la separación de funciones (principio de menor privilegio) reducen el riesgo de escaladas por renombrado o suplantación.

Finalmente, hay una reflexión estratégica: las correcciones actuales —metadatos no confiables, validación de remitentes, limitación de capacidades— amortiguan ataques concretos, pero no resuelven la contradicción de fondo. Un agente útil debe confiar hasta cierto punto en entradas externas; cualquier diseño que busque máxima autonomía y máxima utilidad estará en tensión con los objetivos de seguridad y privacidad. La respuesta a largo plazo pasará por modelos de confianza compuesta: políticas forzadas por la infraestructura, gates humanos para actos críticos, y una mentalidad de "delegación limitada" en la que el agente complementa trabajo humano, no lo sustituye sin supervisión. Para lecturas adicionales y guías prácticas sobre amenazas a agentes y modelos, los blogs técnicos de empresas que investigan estas áreas ofrecen análisis continuos; es recomendable seguir fuentes especializadas como las publicaciones de investigación en seguridad de proveedores y consultoras de ciberseguridad, por ejemplo las secciones de investigación de Imperva y Varonis https://www.imperva.com/blog/ y https://www.varonis.com/blog/.

En resumen: parchear y mitigar ya, pero sobre todo repensar cómo se integra un agente en el perímetro de confianza de la organización. Sin cambios arquitectónicos y operativos, un mensaje inocente o un contacto compartido pueden convertirse en la puerta de entrada para comprometer no solo al agente, sino a los sistemas y los datos que gestiona.