EndpointDetection and Response ha pasado dos décadas respondiendo bien a una pregunta: ¿este proceso está haciendo algo que haría un código malicioso? Comprueba firmas, detecta comportamientos anómalos y señala una escalada de privilegios no autorizada. Un agente de IA con acceso a herramientas rompe la premisa de esa pregunta, no por ser un código malicioso, sino por ser un programa confiable al que se puede convencer para que haga un mal uso de su propio acceso, totalmente legítimo.
La versión anterior a la IA de este problema ya tiene nombre
Usar un programa legítimo y firmado para hacer algo malicioso no es nuevo. MITRE ATT&CK lo cataloga como Ejecución de proxy binario del sistema (T1218): “los archivos binarios firmados con certificados digitales confiables generalmente se pueden ejecutar en sistemas Windows protegidos por validación de firma digital”, que es exactamente la razón por la cual las listas de permitidos y las comprobaciones de firmas tienen problemas una vez que el binario confiable es el que actúa. Un agente de IA extiende la misma debilidad a un programa que no necesita ser precargado con ningún código malicioso: puede ser redirigido en tiempo de ejecución, por el texto que lee.
Un agente secuestrado es un diputado confundido
El término aplicable aquí es problema de diputado confundido: “un programa de computadora que es engañado por otro programa (con menos privilegios o menos derechos) para que haga un mal uso de su autoridad”. Proporcione a un agente herramientas reales, luego déjelo leer contenido que usted no haya examinado y podrá recibir instrucciones de ese contenido. Este es exactamente el patrón que describe Entrada de inyección rápida de OWASP, y ya ha sido demostrado, no sólo teorizado: Informe del 26 de mayo de 2025 de Invariant Labs mostró a un agente codificador, leyendo un número de GitHub de apariencia común en un repositorio público, siguiendo instrucciones ocultas en él para exponer datos de repositorios privados, usando herramientas que le fueron otorgadas legítimamente. La propia conclusión de los investigadores: "esto no es un defecto en el código del servidor GitHub MCP en sí, sino más bien un problema arquitectónico fundamental que debe abordarse a nivel del sistema agente".
process: python3 agent_worker.py --tool-socket 8443
user: developer (normal UID, no privilege escalation)
network: HTTPS POST to a domain the process has contacted before
signature: none matched, no known-bad hash
behaviour: consistent with routine developer tooling
# The same log line is produced whether agent_worker.py just fetched
# documentation the developer asked for, or was redirected by injected
# instructions to read a private file and POST it out.Ese es el punto ciego real: no una brecha en ningún producto, pero el hecho de que la entrada del registro para “el agente hizo su trabajo normal” y “el agente fue secuestrado para hacer un mal uso de su trabajo normal” puede ser idéntica a nivel de proceso. Nada sobre el binario cambió. Nada sobre el patrón de llamada al sistema es nuevo. Solo cambió la intención detrás de la solicitud, y la intención no es un campo en un registro de proceso.
¿Qué realmente reduce esto y qué no?
Vale la pena ser preciso sobre lo que realmente recomienda la persona que nombró este patrón. Simon Willison, quien describió el “Trifecta letal” del acceso a datos privados, la exposición a contenidos no confiables y la comunicación externa juntos en un solo agente, es explícito en que evitar esa combinación es la verdadera solución, no una barrera de seguridad adicional: “la única forma de permanecer seguro es evitar por completo esa combinación letal de trifecta”. Se muestra abiertamente escéptico respecto de los productos que afirman captar de manera confiable instrucciones inyectadas después del hecho, señalando que "todavía no sabemos cómo evitar de manera 100 por ciento confiable que esto suceda" y que una tasa de captura del 95 por ciento es "una calificación muy reprobatoria" para un control de seguridad.
- Primero el diseño: brinde a un agente las herramientas más limitadas y el acceso a los datos que su tarea necesita, de modo que haya menos abuso de una inyección exitosa (la solución arquitectónica que señalan Willison e Invariant Labs).
- Trate cualquier contenido que lea el agente y que usted no haya escrito ni examinado, problemas, páginas recuperadas, archivos descargados, como entrada no confiable, en principio, siempre.
- Cuando el diseño y la revisión no son suficientes, el único paso que un intento de filtración de datos no puede omitir es desconectar la red. Vigilar o restringir eso, por proceso, no evita que un agente sea engañado, pero es una capa real e independiente que no depende del reconocimiento de la instrucción inyectada en primer lugar.
Dónde entran FireAI y HisnLabs
No firewall makes a hijacked agent safe on its own, but the data it tries to send out still has to leave through a socket, and that is the one step FireAI watches regardless of which trusted binary the agent is running inside of.
FireAI es el producto de HisnLabs: un firewall con IA que corre directamente en tu Mac. Te muestra, en lenguaje claro, cada conexión que hacen tus aplicaciones y te deja decidir qué sale de tu Mac; su IA funciona de manera local, así que tu tráfico nunca se envía a nosotros ni a nadie más. El equipo de investigación en seguridad de HisnLabs es el que mantiene esas decisiones confiables: cataloga qué dominios son simple telemetría y cuáles un servicio real, rastrea el país y la red detrás de cada conexión, y entrena el modelo local (la función Autopilot) con patrones de tráfico reales, sin que nada de eso salga de tu Mac.
Puedes leer las decisiones técnicas detrás de FireAI, o probarlo durante 17 días, en FireAI, de HisnLabs.