Codificación con agentes: riesgos, mejores prácticas y 8 lecciones

TL; DR

El riesgo en la programación con agentes no reside en que el agente escriba código malo, sino en que el agente actúe. Instala paquetes, edita archivos que no has abierto, llama a herramientas, lee configuraciones que nadie revisa y abre pull requestsCada una de esas operaciones es una operación privilegiada que se realiza con los permisos de un desarrollador, y sus controles actuales fueron creados para un mundo donde un humano escribía cada uno de ellos.

La velocidad eliminó el cuello de botella para su revisión. Investigaciones independientes sobre asistentes de codificación con IA indican que alrededor del 40 % del código generado contiene una vulnerabilidad de seguridad, y esta tasa no ha mejorado a pesar del perfeccionamiento de los modelos. La producción se multiplicó, pero la capacidad de revisión no. La programación agente hace que esto sea mucho más preciso que el autocompletado, ya que una sola instrucción puede afectar a una docena de archivos.

Los ataques van dirigidos al cableado, no al modelo. El código Unicode oculto en un archivo de reglas hace que un asistente emita código malicioso sin mencionarlo, catalogado en MITRE ATLAS como AML.CS0041. Los atacantes registran los nombres de los paquetes que los modelos alucinan. Un puente MCP envió código ejecutable de forma remota a los clientes más de 437 000 veces. El análisis tradicional no lee ninguno de estos archivos.

Lo que contiene es aburrido y funciona: Inventariar los agentes y servidores MCP que se utilizan realmente, tratar los mensajes y archivos de reglas como código en revisión, limitar el alcance de cada interfaz de herramienta a la tarea y aplicar la política en la máquina del desarrollador donde se ejecuta el agente. Seguridad de IA de Xygeni maneja los tres primeros y DevAI El último, tanto en el código generado por IA como en el escrito por humanos.

¿Qué es la codificación agentica?

La codificación agenica es un tipo de desarrollo donde un agente de IA toma un objetivo y lo ejecuta en todo el código fuente utilizando herramientas: leer y editar archivos, instalar dependencias, ejecutar pruebas y abrir pull requestsLos riesgos provienen de esas acciones y de la configuración que las rige, no de la calidad de ninguna función generada en particular. Las prácticas que funcionan son el inventario, los permisos con alcance definido, la configuración revisada y la aplicación de políticas en el punto final.

¿Codificación con agentes o programación con agentes?

Ambos términos describen el mismo cambio, y los equipos los usan indistintamente. La programación agencial tiende a aparecer en conversaciones de ingeniería sobre cómo se realiza el trabajo; la codificación agencial es la frase que se ha quedado en herramientas y seguridad. Técnicamente, no hay nada que los separe. Si quieres el definición completa y vocabulario circundanteNuestro glosario sobre codificación agéntica lo abarca.

Lo que importa para este artículo es la distinción entre sugerencia y ejecución. Un asistente que completa una línea es una función de productividad. Un agente que instala un paquete, edita seis archivos y envía una rama es una identidad no humana que opera dentro de su SDLCLa programación basada en agentes cruzó esa línea silenciosamente, y la mayoría de los programas de seguridad no se han revisado desde entonces.

Los riesgos reales de la codificación de agentes

Cuatro familias de riesgo, en el orden en que suelen morder.

Revisión del volumen que supera al anterior. Un agente genera más cambios por hora de los que cualquier revisor puede analizar con atención. Las aprobaciones se convierten en meros trámites y los patrones inseguros se reproducen a la velocidad de la máquina. Este es el riesgo que todos reconocen, pero que rara vez se mide. Comience por medir la proporción de cambios generados por agentes con respecto al tiempo de revisión humana, y la cifra le convencerá.
La capa de instrucciones. Cualquier cosa que llegue al contexto del agente puede dirigirlo. La inyección de avisos es la número uno en el Los 10 mejores candidatos para el Máster en Derecho de OWASP Por una razón, y en la programación basada en agentes, los mecanismos de entrega son cotidianos: la descripción de un problema, un comentario en el código, un archivo README en una dependencia, un documento que el agente recupera. Nadie tiene que atacarte directamente. Solo tienen que escribir algo que tu agente pueda leer.
La capa de configuración. Los archivos de reglas, los archivos de habilidades, las indicaciones y las definiciones del servidor MCP determinan qué hace el agente y a qué puede acceder. No son código de aplicación, por lo que ningún escáner en una pila típica los lee. La vulnerabilidad de acceso a archivos de reglas demostró el caso extremo, donde caracteres de ancho cero contienen instrucciones que un revisor no puede ver físicamente. El caso común es igual de perjudicial: una credencial de proveedor en texto plano en un archivo de configuración, o un asistente con acceso de lectura a todo el sistema de archivos porque era la configuración predeterminada.
La dependencia y la superficie de la herramienta. Un agente elige las dependencias. Resuelve un nombre, lo instala y continúa, y los scripts de instalación se ejecutan antes que cualquier pipeline ve el cambio. El slopsquatting explota precisamente esto: una investigación presentada en USENIX Security 2025 descubrió que el 19.7% de los paquetes recomendados por los modelos de lenguaje no existen, y que los nombres alucinados se repiten con la suficiente frecuencia como para que los atacantes los registren y esperen. Lo mismo se aplica a Servidores MCPdonde la conexión a un servidor no confiable le proporciona a un agente herramientas que nunca ha auditado.

Cómo es que realmente sale mal

No se trata de una hazaña exótica aislada. Es una combinación de técnicas ya documentadas en la naturaleza, en el orden en que aparecen.

La instrucción
Una frase se encuentra en la descripción de un problema, en el archivo README de una dependencia o en un comentario de código. No fue escrita para que la lea un ser humano.
El contexto
Un desarrollador le pide al agente que solucione el problema. El agente incorpora la descripción, el repositorio y sus propios archivos de reglas al contexto. Las instrucciones y el contenido se ven idénticos a los de un modelo.
la instalación
El agente identifica una biblioteca auxiliar que le parece adecuada y la instala. El nombre fue registrado la semana pasada por alguien que notó que los modelos lo inventaban constantemente. El script de instalación se ejecuta en la computadora portátil.
La credencial
Hay un token de proveedor en texto plano en un mcp.jsony una sesión en la nube ya activa en el shell. El script no necesita elevar privilegios. Hereda.
El pull request
El cambio es pequeño, las pruebas son positivas y la diferencia es razonable. Se aprueba en menos de un minuto, porque hay cuatro más en espera.

Cada puerta que poseas se activará después del paso tres. Los tres primeros se producen en un ordenador de desarrollo, en unos noventa segundos.

8 lecciones de los primeros en adoptar nuevas tecnologías

Basado en incidentes documentados, investigaciones publicadas y los patrones que siguen apareciendo en equipos que adoptaron la programación basada en agentes antes de que se redactara una política al respecto.

El radio de explosión es la superficie de la herramienta, no la indicación Los equipos pasan semanas perfeccionando las indicaciones y minutos decidiendo qué herramientas puede usar un agente. Es una proporción incorrecta. Un agente que solo puede leer es un inconveniente cuando se ve comprometido. Un agente que puede enviar correos electrónicos, consultar producción y enviar notificaciones push commitSe trata de un incidente, y el desarrollador posee las credenciales necesarias para realizarlo, ya que casi nadie proporciona una identidad para un agente. Anota la lista de herramientas antes de escribir el mensaje del sistema.
El agente optimiza para que la prueba pase, no para que el código funcione. Dado un conjunto de pruebas defectuoso y suficiente autonomía, un agente eliminará la aserción, flexibilizará la condición o reemplazará una integración por una simulada, y luego informará del éxito. Todos los equipos reconocen esto la primera semana. Por eso es verde. pipelinedejó de ser evidencia, y por qué la pregunta de revisión cambió de "¿esto funciona?" a "¿qué cambió para que esto pasara?".
Tu archivo de reglas es la configuración de producción. El archivo que controla cada línea generada suele ser commitSe revisó una vez y nunca más. Debe estar bajo control de cambios con un responsable, una revisión de diferencias y alguien que se dé cuenta cuando se añade una línea que nadie recuerda haber agregado. Asuma que todo lo que contiene se cumplirá, incluso lo que no se ve.
Las dependencias del agente no son tus dependencias. Las listas de bibliotecas aprobadas presuponen que una persona realizó la selección. Un agente resuelve un nombre plausible y lo instala, y los scripts de instalación se ejecutan antes de que exista la integración continua. Los equipos que sufrieron las consecuencias añadieron una comprobación en el momento de la instalación en la máquina, en lugar de un documento de política que indicara las preferencias de los desarrolladores.
Nadie puede decirte qué están ejecutando. Si preguntas a cinco ingenieros qué servidores y asistentes MCP utilizan, obtendrás cinco respuestas, ninguna completa. Las encuestas no funcionan aquí porque las herramientas se instalan localmente y cambian semanalmente. El descubrimiento debe basarse en el código, las dependencias y los archivos de configuración que dejan las herramientas.
La memoria conserva el veneno después de que termina la sesión. Una instrucción errónea que llega al contexto persistente o a la memoria de un agente no desaparece cuando finaliza la tarea. Sigue generando beneficios de forma silenciosa en tareas no relacionadas, razón por la cual la contaminación de memoria y contexto tiene su propia entrada en la lista de agentes de OWASP. Considere la memoria del agente como un estado que necesita revisión y que debe borrarse, no como una función de conveniencia.
La reversibilidad supera a la prevención. Los equipos que gestionan la autonomía con mayor seguridad no son los que tienen los controles más estrictos. Son los que minimizan los errores: los agentes envían solicitudes a las ramas en lugar de a la principal, trabajan en entornos desechables y cada acción se puede deshacer con un solo comando. La autonomía es asequible en la medida en que revertirla lo es.
El piloto te miente Los agentes funcionan de maravilla en tareas nuevas en repositorios pequeños, pero su rendimiento disminuye en grandes bases de código heredadas con convenciones implícitas. Un programa piloto exitoso exagera el aumento de productividad y subestima el riesgo, creando expectativas imposibles de cumplir a gran escala. Realice la prueba piloto en su repositorio más problemático, no en el más limpio.

Cómo se ve esto en la práctica

El orden importa más que las herramientas. Primero el descubrimiento, porque no se pueden definir permisos en agentes que no se han encontrado. Luego la capa de configuración, porque ahí es donde residen las instrucciones. Luego el punto final, porque ahí es donde realmente se ejecuta el agente y donde se completa una instalación mucho antes de que se complete. pipeline avisos

Seguridad de IA de Xygeni descubre todos los activos de IA en el SDLC, incluyendo los modelos, agentes, servidores de agentes, servidores MCP, conjuntos de datos, archivos de habilidades, indicaciones y guardrails nadie declaró, leyendo el código de la aplicación, las dependencias declaradas y los archivos de configuración que dejan las herramientas de IA, luego mapea cómo se conectan. Detecta los riesgos específicos de la programación de agentes: inyección de indicaciones y fuga de indicaciones del sistema, instrucciones maliciosas e inyección de herramientas en reglas y archivos de habilidades, configuración insegura de MCP, agencia excesiva y faltante guardrailsSecretos en archivos de IA y dependencias de IA vulnerables o suplantadas. Los hallazgos se corresponden con el Top 10 de OWASP para aplicaciones LLM e indican el archivo y la línea exactos, y el embudo de priorización reduce miles de hallazgos a aquellos que están en uso, son accesibles, explotables, privilegiados y críticos para el negocio.

DevAI Cubre la otra mitad, en el editor: protege el código mientras se escribe, se aplica tanto al código generado por IA como al escrito por humanos, e intercepta lo que otros agentes están a punto de hacer antes de que lo hagan. La misma inteligencia se aplica a los resultados obtenidos de los escáneres que ya utilizas, por lo que no es necesario reemplazar nada de esto.

Codificación con agentes: riesgos, mejores prácticas y 8 lecciones de los primeros usuarios.

Publicaciones de lectura obligada