TL;DR: Ingeniería de agentes y su superficie de ataque oculta
La ingeniería de aprovechamiento de agentes es la práctica de construir todo lo necesario alrededor de un modelo de IA (instrucciones, herramientas, permisos, memoria y bucles de retroalimentación) para convertirlo en un agente funcional. Es en ese arnés, y no en el modelo, donde reside ahora la mayor parte del riesgo real para la seguridad.
- El cambio: Los equipos dejaron de ajustar las indicaciones y comenzaron a diseñar arneses. Agente = modelo + arnés.
- El problema: El sistema reside en archivos de texto plano (reglas, habilidades, configuraciones de MCP) que se revisan como documentación, si es que se revisan.
- La evidencia: El archivo de reglas de puerta trasera y las vulnerabilidades CVE reales de MCP demuestran que los atacantes ya lo tienen en la mira.
- La solución: Trate el arnés como si fuera un código. Inventívelo, revíselo y escanéelo antes de enviarlo.
Toda conversación sobre seguridad relacionada con la IA termina girando en torno al modelo. ¿Se le puede hacer jailbreak? ¿Alucinará? ¿El proveedor se está entrenando con nuestros datos?
Son preguntas válidas, pero cada vez más erróneas. Cuando un agente de IA elimina una tabla de producción, abre una puerta trasera o envía una lista de clientes por correo electrónico a un desconocido, rara vez el fallo se debe al modelo. El modelo hizo exactamente lo que su sistema le permitía.
Agente = modelo + arnés
Durante el último año, la industria cambió silenciosamente lo que significa construir con IA. La ingeniería de inmediatez dio paso a la ingeniería de contexto, y la ingeniería de contexto dio paso a algo más grande: ingeniería de arnés de agente.
La idea es sencilla. Un modelo, por sí solo, es un motor de razonamiento sin manos. El arnés es todo lo que le da manos y una función: las instrucciones que sigue, las herramientas que puede usar, los permisos que posee, la memoria que almacena y las comprobaciones que detectan sus errores. Sitio web de Martin Fowler describe la ingeniería de arnés como el trabajo que los usuarios de agentes de codificación ahora hacen para hacer que los agentes sean confiables y un Marco académico publicado este año Divide el sistema en once responsabilidades, desde el acceso a las herramientas y la memoria del proyecto hasta los permisos y la verificación.
Los resultados son reales. Los equipos que practican la ingeniería de arneses de agentes informan que cambiar solo el arnés, manteniendo el mismo modelo subyacente, puede modificar drásticamente los resultados de un agente. Esto plantea una cuestión incómoda para cualquier persona en el ámbito de la seguridad: si el arnés determina cómo se comporta el agente, también determina cómo se puede abusar de él.
Tomemos como ejemplo algo tan común como instalar una dependencia. Un desarrollador se detiene a verificar el nombre del paquete. Un agente con la herramienta adecuada simplemente ejecuta el comando, y si el paquete es malicioso, nada en el modelo lo detendrá. Eso es precisamente lo que analizamos en este episodio de SafeDev Talks: ¿Qué cambia cuando los agentes de IA instalan dependencias? por sí solos, y por qué la ingeniería de aprovechamiento de agentes se ha convertido silenciosamente en un problema de la cadena de suministro.
Cómo se ve la ingeniería de aprovechamiento de agentes en un repositorio
Abre un repositorio donde los desarrolladores utilicen agentes de IA y la herramienta estará ahí mismo, en archivos que probablemente nunca hayas escaneado:
- Archivos de reglas e instrucciones (
AGENTS.md,.cursorrules(Instrucciones del copiloto) que le indican al agente cómo comportarse. - Archivos de habilidades ese paquete de capacidades reutilizables que el agente carga bajo demanda.
- Configuraciones del servidor MCP que conectan al agente con herramientas, bases de datos y API.
- Mensajes del sistema y plantillas de mensajes integrado en el código de la aplicación.
- Cableado del agente: qué herramientas puede utilizar un agente, qué datos puede recuperar y si existe alguna medida de seguridad que lo impida.
Todo es texto plano. Todo es commitjunto con el código. Y todo se revisa como se revisa la documentación: un vistazo rápido, una aprobación, una fusión. Sin embargo, cada uno de estos archivos puede reescribir silenciosamente lo que se le indica a un agente que haga y lo que se le permite modificar.
Esa es la verdadera consecuencia de la ingeniería de sistemas de agentes: la configuración más potente de su software es ahora la que menos se revisa.
Los atacantes ya lo notaron
Esto no es una preocupación teórica. El arnés tiene un historial de incidentes breve pero revelador.
- El acceso oculto al archivo de reglas. En marzo de 2025, investigadores revelaron un ataque en el que caracteres Unicode ocultos dentro de un archivo de reglas instruían a los asistentes de codificación de IA a insertar código malicioso, sin mencionarlo en su respuesta visible. Un revisor que leyó el archivo no vio nada inusual. Ahora está catalogado como MITRE ATLAS Caso de éxito AML.CS0041.
- Herramientas MCP envenenadas. Hasta 2025, los investigadores demostraron repetidamente que los agentes confían implícitamente en las descripciones de las herramientas, por lo que un servidor MCP malicioso puede dirigir a un agente simplemente describiéndose a sí mismo de la manera correcta. Ese mismo año, CVE-2025-6514 Un cliente MCP muy descargado permitía la ejecución remota de comandos al conectarse a un servidor no confiable, con una calificación de 9.6 en CVSS.
- Autonomía excesiva. El Los 10 mejores candidatos para el Máster en Derecho de OWASP enumera la agencia excesiva como un riesgo principal: agentes otorgados más herramientas, permisos o autonomía de la que requiere la tarea. Eso no es un defecto del modelo. Es un diseño de arnés.cision.
Fíjense en el patrón. Ninguno de estos ataques rompe el modelo. Rompen el sistema de control, y el modelo hace el resto fielmente.
Por qué su conjunto de seguridad no lo detecta
Aquí viene la parte incómoda. La mayoría de las organizaciones ya utilizan buenas herramientas de seguridad de aplicaciones, y casi ninguna de ellas fue diseñada para esta capa.
El análisis estático comprende el código, pero desconoce qué es un modelo o por qué importa el texto no confiable que llega a la solicitud del sistema. El análisis de composición inventaría los paquetes, pero no enumera los servidores MCP ni los archivos de habilidades. Los escáneres de Secreto pueden pasar por alto una clave API en un archivo de configuración del agente. Ninguna de estas herramientas es defectuosa. Simplemente fueron diseñadas para un entorno donde la configuración no dictaba órdenes.
Por lo tanto, el desarrollo del arnés de agentes avanza rápidamente, y la seguridad revisa la parte que puede ver: el modelo y el código. El arnés se sitúa en un punto intermedio.
Cinco hábitos para asegurar el arnés
Para garantizar la seguridad en la ingeniería de la interfaz de agentes, no se necesita un nuevo equipo. Se necesitan algunos hábitos que traten la interfaz como lo que es: una intención ejecutable.
| Hábito | Por qué importa | Qué hacer |
|---|---|---|
| 1. Inventarie cada arnés | No puedes asegurar agentes que nadie haya declarado. | Encuentra todos los modelos, agentes, servidores MCP, habilidades y sugerencias en tus repositorios, directamente desde los archivos de código y configuración, en lugar de mediante una encuesta. |
| 2. Revisar los archivos de arnés como el código | Las reglas, las habilidades y las configuraciones de MCP pueden reescribir lo que hace un agente, pero se revisan como si fueran documentación. | Dales lo mismo pull request El análisis se realiza como lógica de aplicación, incluyendo comprobaciones de caracteres ocultos. |
| 3. Fijar lo que carga el agente | Se puede cambiar la referencia a una solicitud o modelo mediante una etiqueta mutable sin necesidad de modificar el código. | Fije las indicaciones y los modelos a versiones inmutables. |
| 4. Coloca una barandilla en cada lavabo. | Los documentos recuperados, los resultados de las herramientas y el contenido del usuario pueden contener instrucciones inyectadas en el modelo. | Coloca una barrera de protección en el camino dondequiera que ese contenido pueda llegar al modelo. |
| 5. Mantenga las credenciales fuera del arnés. | Las claves de los proveedores de IA en los archivos de configuración de los agentes y en las solicitudes de acceso son un blanco fácil para un atacante. | Elimínalos y continúa escaneando los archivos del arnés en busca de Secretos. Es una solución sencilla. |
Asegurar el arnés, no solo el modelo.
Seguridad de IA de Xygeni comienza donde la ingeniería de aprovechamiento de agentes deja su huella: en sus repositorios. Descubre los activos de IA en toda su base de código (modelos, agentes, servidores MCP, habilidades, indicaciones, guardrailsy las herramientas de codificación de IA en uso) a partir del código, las dependencias y los archivos de configuración que dejan esas herramientas.
A continuación, analiza los archivos de habilidades, los archivos de reglas y las configuraciones de MCP como artefactos de seguridad, no como documentación, y detecta riesgos de inyección de mensajes en el cableado del agente, como contenido no confiable que llega a un mensaje del sistema o a un destino de recuperación sin protección. El escaneo Secretos de Xygeni marca las credenciales del proveedor de IA en los mensajes y los archivos de configuración del agente, y las dependencias de su pila de IA reciben la misma detección de malware que todo lo demás, antes de que exista una firma.
Preguntas Frecuentes
¿Qué es la ingeniería de arneses de agentes?
La ingeniería de entornos para agentes es la disciplina que diseña el entorno que rodea a un modelo de IA (instrucciones, herramientas, permisos, memoria, contexto y bucles de verificación) para que se comporte como un agente fiable. El modelo proporciona el razonamiento; el entorno decide qué puede ver y hacer el agente.
¿En qué se diferencia la ingeniería de gestión de agentes de la ingeniería de indicaciones?
La ingeniería de indicaciones da forma a una sola instrucción. La ingeniería del sistema del agente da forma a todo el sistema en el que opera el agente, a través de múltiples pasos, herramientas y sesiones. Una indicación es un archivo en el sistema.
¿Por qué el arnés supone un riesgo para la seguridad?
Porque controla lo que un agente puede hacer y reside en archivos de texto plano que rara vez se revisan como artefactos de seguridad. Si se compromete un archivo de reglas o una configuración de MCP, se controla el agente sin modificar el modelo.
¿Quién debería ser el propietario del agente de seguridad?
Seguridad de la aplicación: colaboración con los ingenieros que desarrollan y configuran los agentes. El arnés forma parte del software que distribuye, por lo que debe someterse a los mismos procesos de revisión, escaneo e inventario que el resto del código.
