Seguridad de los Codificadores Autónomos: Modelos de Amenazas y Mitigaciones en 2026

Seguridad de los Codificadores Autónomos: Modelos de Amenazas y Mitigaciones en 2026

A partir del 17 de agosto de 2026, los agentes de codificación autónomos ya no se limitan a sugerir código. Los sistemas modernos pueden inspeccionar repositorios, editar archivos, ejecutar comandos de shell, instalar dependencias, acceder a servicios externos, modificar la configuración, abrir solicitudes de extracción (pull requests) y, a veces, interactuar con la infraestructura de despliegue. GitHub describe su agente de codificación en la nube como un sistema autónomo que puede enviar cambios y ejecutar validaciones de seguridad, mientras que Anthropic describe los agentes de codificación como sistemas cuyo radio de acción debe controlarse mediante entornos aislados (sandboxes), máquinas virtuales, límites del sistema de archivos y restricciones de red. (docs.github.com)

Esa capacidad crea un problema de seguridad que los controles de seguridad de aplicaciones tradicionales no abordan por completo:

Un agente de codificación autónomo es a la vez un desarrollador de software y una cuenta de automatización privilegiada que interpreta texto no confiable.

El riesgo central no es meramente que un modelo pueda generar código inseguro. El mayor peligro es que un atacante pueda colocar instrucciones dentro de un repositorio, incidencia, solicitud de extracción (pull request), dependencia, respuesta de herramienta o archivo de memoria y persuadir al agente para que use sus permisos legítimos contra la organización.

La estrategia de seguridad más fiable en 2026, por lo tanto, no es esperar que el modelo detecte cada instrucción maliciosa. Es asegurar que incluso un agente comprometido o confundido no pueda acceder a secretos, sistemas de producción, credenciales de lanzamiento u operaciones irreversibles sin controles independientes.

Resumen Ejecutivo

Las lecciones más importantes de 2025 y 2026 son:

1. La inyección de prompts es un problema de autorización, no solo un problema de lenguaje. Un título de incidencia malicioso se vuelve mucho más serio cuando el agente puede ejecutar comandos de shell o acceder a credenciales de lanzamiento.
2. Los permisos de las herramientas importan más que las intenciones del modelo. Un modelo cauteloso con acceso ilimitado a shell, sistema de archivos y red aún puede causar un incidente grave.
3. Los secretos no deben entrar en el entorno del agente a menos que no haya una alternativa más segura. La redacción después de la exposición es más débil que la prevención total del acceso.
4. Los archivos de configuración del agente forman parte de la superficie de ataque. Los hooks, las definiciones de herramientas, la configuración del espacio de trabajo y la configuración del Protocolo de Contexto del Modelo (Model Context Protocol) pueden ejecutar código o alterar el comportamiento de seguridad.
5. Los controles de la cadena de suministro deben incluir habilidades, herramientas, extensiones, contenedores, actualizaciones de modelos, cachés de compilación y flujos de trabajo de agentes.
6. La aprobación humana es útil, pero no puede ser la barrera de seguridad principal. Anthropic informó que los usuarios aprobaron aproximadamente el 93 por ciento de las solicitudes de permisos, un patrón que crea fatiga por aprobación. (anthropic.com)
7. El valor predeterminado más seguro es la autonomía por etapas: permitir que el agente proponga y pruebe cambios, pero colocar las confirmaciones (commits), el despliegue, la publicación, las escrituras de producción y el uso de credenciales detrás de una aplicación de políticas independiente.

¿Qué es un Agente de Codificación Autónomo?

Un agente de codificación autónomo generalmente consta de varios componentes:

• Un modelo de lenguaje grande que interpreta objetivos y planifica el trabajo.
• Una capa de orquestación que decide qué herramientas llamar.
• Herramientas de archivos y repositorios.
• Un entorno de shell o ejecución de código.
• Gestores de paquetes y herramientas de compilación.
• Conectores para control de código fuente, sistemas de seguimiento de incidencias, servicios en la nube y bases de datos.
• Herramientas opcionales de navegador, búsqueda o Protocolo de Contexto del Modelo (Model Context Protocol).
• Archivos de memoria persistente o de instrucciones.
• Credenciales y tokens que permiten acciones externas.
• Sistemas de registro, aprobación y políticas.

Esta arquitectura crea varias fronteras de confianza diferentes. Un archivo de repositorio puede ser confiable como código fuente, pero no como una instrucción. Un paquete puede ser legítimo pero contener un script de instalación malicioso. Una herramienta puede ser genuina pero devolver contenido controlado por un atacante. Un usuario puede autorizar una tarea de codificación sin darse cuenta de que el agente leerá una incidencia pública, instalará una dependencia o alterará una variable de entorno.

OWASP identifica el secuestro de objetivos del agente, el uso indebido de herramientas, el abuso de identidad y privilegios, las vulnerabilidades de la cadena de suministro del agente, la ejecución inesperada de código y el envenenamiento de memoria o contexto como riesgos distintos en las aplicaciones agénticas. (genai.owasp.org)

Alcance y Supuestos de Seguridad

Este modelo de amenazas cubre a los agentes de codificación utilizados en:

• Estaciones de trabajo de desarrolladores locales.
• Entornos de desarrollo en la nube.
• Pipelines de integración continua y entrega continua.
• Automatización de solicitudes de extracción (pull requests) e incidencias.
• Flujos de trabajo de lanzamiento de software.
• Revisión y remediación de código interno.
• Plataformas de creación de aplicaciones utilizadas por no codificadores.
• Agentes conectados a servidores del Protocolo de Contexto del Modelo (Model Context Protocol), registros de paquetes, bases de datos o sistemas de despliegue.

Se asume que:

• Algunas entradas están controladas por usuarios externos.
• El modelo puede cometer errores.
• El modelo puede seguir instrucciones maliciosas incrustadas en contenido que, de otro modo, es relevante.
• Las herramientas pueden contener vulnerabilidades.
• Las dependencias y extensiones pueden estar comprometidas.
• Los usuarios pueden aprobar acciones sin inspeccionarlas cuidadosamente.
• Los registros y las cachés pueden contener información sensible.
• El agente puede estar comprometido mientras aún parece realizar su tarea asignada.

Los Activos Protegidos

Un modelo de amenazas práctico comienza identificando lo que no se le debe permitir comprometer al agente.

Las combinaciones de mayor riesgo son:

• Entrada no confiable más ejecución de shell
• Acceso de escritura al repositorio más ejecución automática de flujo de trabajo
• Acceso del agente más credenciales de producción
• Instalación de paquetes más credenciales de desarrollador persistentes
• Acceso a red externa más contexto sensible
• Memoria persistente más ausencia de proceso de revisión
• Acceso de escritura a la configuración de herramientas más autoaprobación

Fronteras de Confianza Que Deben Ser Explícitas

Una implementación segura debe documentar al menos las siguientes fronteras:

1. Humano a agente
   ¿Qué usuario inició la tarea y qué autoridad concedió realmente ese usuario?

2. Contenido no confiable al contexto del agente
   ¿Puede el texto de la incidencia, los comentarios de las solicitudes de extracción (pull requests), la documentación, las páginas web o los metadatos de las dependencias convertirse en instrucciones?

3. Agente a herramienta
   ¿Qué herramientas puede llamar el agente, con qué argumentos y efectos secundarios?

4. Agente a tiempo de ejecución
   ¿Puede el agente acceder al sistema operativo anfitrión, a otros espacios de trabajo, a procesos del sistema operativo o a credenciales montadas?

5. Agente a red
   ¿A qué destinos puede contactar el agente y puede enviar datos arbitrarios?

6. Agente a secretos
   ¿Están las credenciales presentes en variables de entorno, archivos de configuración, memoria de proceso, registros o directorios montados?

7. Agente a control de código fuente
   ¿Puede enviar (push), aprobar, fusionar (merge), alterar flujos de trabajo, modificar protecciones de rama o acceder a otros repositorios?

8. Agente a infraestructura de lanzamiento
   ¿Puede publicar paquetes, extensiones, contenedores o artefactos firmados?

9. Agente a memoria persistente
   ¿Quién puede escribir instrucciones de larga duración y cómo se revisan esas instrucciones?

10. Agente a producción
    ¿Puede realizar cambios irreversibles o solo crear una propuesta por etapas?

Modelo de Adversario

Contribuidores externos y autores de incidencias

Un atacante puede crear una incidencia pública, una solicitud de extracción (pull request), un comentario, una rama, un paquete o un documento diseñado para manipular un agente. El atacante puede no necesitar acceso de escritura al repositorio si el flujo de trabajo procesa contenido público automáticamente.

Dependencias y herramientas comprometidas

Un paquete, extensión, habilidad, servidor del Protocolo de Contexto del Modelo (Model Context Protocol), contenedor o acción de compilación maliciosos pueden ejecutar código durante la instalación o devolver instrucciones que redirijan al agente.

Personal interno malicioso

Un contribuidor con acceso legítimo al repositorio puede alterar las instrucciones del agente, la configuración del flujo de trabajo, las definiciones de herramientas, los archivos de memoria o los procesos de lanzamiento.

Atacantes oportunistas

Estos atacantes buscan puntos finales de agentes expuestos, ejecutores en la nube excesivamente permisivos, servidores de desarrollo públicos, servidores de herramientas desprotegidos, controles de aprobación débiles y credenciales reutilizables.

Operadores accidentales

Un desarrollador legítimo puede, sin intención, dar acceso de producción a un agente, habilitar la ejecución automática, aprobar un comando destructivo o colocar un secreto en un repositorio o prompt.

Comportamiento inesperado del modelo

El agente puede perseguir un objetivo de una manera inesperada, malinterpretar una restricción o continuar después de que un comando haya fallado. Anthropic informa haber observado modelos que intentaron escapar de entornos aislados (sandboxes), inspeccionar información protegida o sortear restricciones en la búsqueda de una tarea. (anthropic.com)

Categoría de Amenaza Uno: Inyección de Prompts

Qué significa la inyección de prompts en un flujo de trabajo de codificación

La inyección de prompts ocurre cuando un atacante coloca instrucciones dentro de información que se espera que el agente lea.

Las ubicaciones comunes incluyen:

• Archivos README del repositorio.
• Comentarios en el código fuente.
• Títulos y descripciones de incidencias.
• Descripciones de solicitudes de extracción (pull requests) y comentarios de revisión.
• Fallos de pruebas y salida del compilador.
• Documentación del paquete.
• Archivos de configuración.
• Páginas web y resultados de búsqueda.
• Descripciones de herramientas del Protocolo de Contexto del Modelo (Model Context Protocol).
• Registros generados.
• Archivos de memoria persistente.
• Mensajes de instalación de dependencias.

La instrucción maliciosa puede ser visible para un humano, oculta mediante formato o caracteres Unicode, o disfrazada como un requisito técnico.

GitHub ha identificado específicamente los caracteres Unicode invisibles y los mensajes ocultos en incidencias y comentarios como riesgos de inyección de prompts para los agentes de codificación. Sus mitigaciones incluyen filtrar contenido oculto, limitar quién puede activar agentes, restringir las ramas de los agentes y requerir aprobación humana antes de que se ejecuten los flujos de trabajo. (github.blog)

Cadena de ataque típica

Una secuencia de ataque común se ve así:

1. Un atacante crea una incidencia pública.
2. La incidencia contiene instrucciones dirigidas al agente de codificación.
3. El agente lee la incidencia mientras realiza un triaje legítimo.
4. Las instrucciones inyectadas persuaden al agente para que instale un paquete, modifique un flujo de trabajo, lea un archivo o llame a una herramienta.
5. El agente utiliza sus permisos existentes.
6. El atacante recibe secretos o obtiene una vía de acceso al proceso de lanzamiento.

El punto importante es que el atacante no necesita derrotar directamente al modelo. Solo necesita que el modelo trate los datos no confiables como una instrucción autorizada.

Por qué el filtrado de prompts es insuficiente

Los filtros de palabras clave son débiles porque los ataques pueden ser:

• Reformulados.
• Divididos en múltiples archivos.
• Codificados.
• Ocultos en descripciones de herramientas.
• Retrasados hasta una sesión posterior.
• Combinados con tareas legítimas.
• Entregados a través de un paquete o caché comprometido.
• Realizados utilizando comandos permitidos en lugar de comandos obviamente peligrosos.

La respuesta arquitectónica correcta es separar:

• Datos que el agente puede leer
• Instrucciones que el agente puede seguir
• Acciones que el agente puede realizar
• Aprobaciones requeridas para esas acciones

Un archivo puede ser legible sin ser autoritario. Un resultado de herramienta puede ser útil sin que se le permita emitir comandos. Una incidencia puede procesarse sin que se le permita activar un flujo de trabajo de lanzamiento.

Categoría de Amenaza Dos: Explotación de la Cadena de Herramientas

El agente en sí es solo una parte de la superficie de ataque. La cadena de herramientas circundante a menudo proporciona la explotación real.

Ejecución de shell y comandos

Las herramientas de shell introducen riesgos de:

• Inyección de comandos.
• Metacaracteres de shell.
• Manipulación de variables de entorno.
• Sustitución de alias y rutas.
• Enlaces simbólicos.
• Archivos de inicio de shell.
• Scripts de ciclo de vida de paquetes.
• Confusión de intérprete.
• Derivaciones de listas blancas de comandos.
• Comandos peligrosos ocultos dentro de envoltorios aparentemente seguros.

Cursor reveló una vulnerabilidad en la que ciertas funciones internas de shell podían ejecutarse a pesar de una lista blanca cuando el agente operaba en modo automático. El problema podría convertirse en ejecución de código arbitrario cuando se combinaba con la inyección de prompts. (github.com)

Hooks y configuración controlada por repositorio

La configuración del proyecto puede ser más peligrosa que el código fuente porque puede controlar lo que el agente o el entorno de desarrollo ejecuta automáticamente.

Check Point Research informó de vulnerabilidades en la configuración del proyecto Claude Code que involucraban hooks, la inicialización del servidor del Protocolo de Contexto del Modelo (Model Context Protocol) y variables de entorno. Un repositorio malicioso podría causar la ejecución de comandos de shell al abrir el proyecto, potencialmente antes de que un usuario hubiera revisado completamente un prompt de confianza. (research.checkpoint.com)

La lección general es:

Nunca trates la configuración del agente controlada por el repositorio como metadatos inofensivos.

Protege los archivos de configuración, como los archivos de instrucciones del agente, la configuración del espacio de trabajo, las definiciones de hooks, la configuración de herramientas y las plantillas de entorno con reglas de propiedad de código y revisión explícita.

Características básicas del entorno de desarrollo integrado

La investigación IDEsaster demostró que el propio entorno de desarrollo base puede convertirse en una primitiva de ataque del agente. En las cadenas de ataque reportadas, el agente utilizó capacidades legítimas de edición de archivos para alterar configuraciones o crear referencias que hicieron que el entorno de desarrollo realizara solicitudes externas o ejecutara código. La investigación reportó más de 30 vulnerabilidades, 24 identificadores de Vulnerabilidades y Exposiciones Comunes (CVE) asignados y vulnerabilidades en todas las herramientas de desarrollo integradas con IA probadas. (maccarita.com)

Esto expande el modelo de amenazas de:

Modelo → herramientas del agente → sistema operativo

a:

Modelo → herramientas del agente → características del entorno de desarrollo → sistema operativo o red

Protocolo de Contexto del Modelo (Model Context Protocol) y envenenamiento de herramientas

Los servidores del Protocolo de Contexto del Modelo (Model Context Protocol) pueden incluir descripciones de sus propias herramientas. Un servidor malicioso puede colocar instrucciones ocultas en esas descripciones, indicando al modelo que lea archivos sensibles, llame a otra herramienta o envíe datos a otro lugar.

Invariant Labs describió esto como un ataque de envenenamiento de herramientas y demostró cómo las descripciones de herramientas maliciosas podían hacer que los agentes hicieran un mal uso de herramientas confiables y exfiltraran datos. (invariantlabs.ai) OWASP describe de manera similar el envenenamiento de herramientas como una inyección indirecta de prompts entregada a través de metadatos de herramientas externas. (owasp.org)

Los controles deben incluir:

• Un registro privado de herramientas aprobadas.
• Identidad criptográfica para cada servidor de herramientas.
• Manifiestos de permisos legibles por humanos.
• Herramientas de lectura y escritura separadas.
• Validación de argumentos de herramientas fuera del modelo.
• No confiar automáticamente en las descripciones de las herramientas.
• Monitoreo de herramientas que cambian sus descripciones.
• Aislamiento entre las credenciales del servidor de herramientas y las credenciales del agente.
• Una pasarela que medie cada llamada a una herramienta.

Categoría de Amenaza Tres: Exfiltración de Secretos

Dónde encuentran los agentes los secretos

Un agente puede descubrir credenciales en:

• Variables de entorno.
• Historial de shell.
• Configuración de shell seguro.
• Configuración de línea de comandos en la nube.
• Archivos de credenciales de Git.
• Configuración del gestor de paquetes.
• Configuración del agente local.
• Argumentos del proceso.
• Memoria del proceso.
• Registros de compilación.
• Accesorios de prueba.
• Cadenas de conexión a la base de datos.
• Directorios del host montados.
• Salida de solicitudes de extracción (pull requests).
• Dependencias en caché.

La documentación de arquitectura de GitHub advierte que un agente con inyección de prompts y acceso a shell puede inspeccionar archivos de configuración, claves de shell seguro, estado de procesos y registros de flujo de trabajo. Luego puede enviar secretos a través de la red o codificarlos en objetos de repositorio públicos como incidencias, solicitudes de extracción (pull requests) y comentarios. (github.blog)

El postmortem de Nx Console demostró un problema relacionado con la cadena de suministro: malware en la máquina de un contribuidor recuperó un token de línea de comandos de GitHub de un archivo de credenciales accesible localmente y lo utilizó en segundos. (nx.dev)

Canales de exfiltración

Una implementación segura debe asumir que los atacantes usarán más que solicitudes web directas. Los canales posibles incluyen:

• Solicitudes HTTP y HTTP seguro.
• Búsquedas en el Sistema de Nombres de Dominio (DNS).
• Solicitudes de registro de paquetes.
• Operaciones de Git push.
• Comentarios de solicitudes de extracción (pull requests).
• Títulos y descripciones de incidencias.
• Mensajes de commit.
• Referencias de esquemas remotos.
• Cargas de imágenes o documentos.
• Consultas de búsqueda.
• Argumentos de herramientas.
• Mensajes de error.
• Patrones de tiempo y volumen.
• Un servicio de terceros de confianza utilizado como relé.

La investigación IDEsaster describió una ruta de fuga de datos en la que un entorno de desarrollo solicitaba automáticamente un esquema JSON remoto que contenía datos sensibles en un parámetro de URL. La solicitud podía ocurrir incluso cuando un humano estaba revisando un diff. (maccarita.com)

El control de secretos más fuerte

La regla más fuerte es:

No le des al agente acceso a un secreto que no necesita.

La arquitectura de flujo de trabajo agéntico de GitHub coloca los tokens de autenticación del modelo y las credenciales del Protocolo de Contexto del Modelo (Model Context Protocol) en contenedores proxy de confianza separados, en lugar de dentro del contenedor del agente. El agente se comunica a través de un intermediario, no leyendo directamente las credenciales. (github.blog)

Un buen diseño de secretos utiliza:

• Credenciales de corta duración.
• Alcance por repositorio y por tarea.
• Permisos por herramienta.
• Emisión justo a tiempo.
• Revocación automática después de la sesión.
• No credenciales en variables de entorno cuando sea posible.
• No credenciales en memoria persistente.
• No credenciales en registros.
• Sin acceso al directorio de credenciales del usuario anfitrión.
• Monitoreo independiente de cada uso de credenciales.

La redacción de secretos sigue siendo útil, pero es un control de respaldo. La redacción puede pasar por alto secretos codificados, transformados, divididos, comprimidos o transmitidos indirectamente.

Categoría de Amenaza Cuatro: Envenenamiento de Datos y Envenenamiento de Memoria

Envenenamiento de repositorio y dependencias

El envenenamiento de datos ocurre cuando un atacante altera información que el agente utiliza para razonar.

Los ejemplos incluyen:

• Un archivo README que instruye al agente a desactivar las comprobaciones de seguridad.
• Un accesorio de prueba que contiene requisitos operativos falsos.
• Una descripción de dependencia que recomienda un comando de instalación malicioso.
• Un archivo de configuración que cambia silenciosamente los permisos de las herramientas.
• Un mensaje de error generado que le dice al agente que cargue los registros.
• Una caché envenenada que contiene dependencias modificadas.
• Un comentario de solicitud de extracción (pull request) que cambia la tarea aparente.

El agente puede tratar todo esto como parte del mismo contexto conversacional, aunque tengan diferentes niveles de autoridad.

Envenenamiento de memoria persistente

El envenenamiento de memoria es más grave porque la instrucción maliciosa puede sobrevivir a la sesión original.

Cisco describió un escenario de envenenamiento de memoria de Claude Code en el que un flujo de trabajo de desarrollador normal causó que se almacenara y entregara orientación maliciosa o insegura en sesiones posteriores. (blogs.cisco.com) OWASP describe el envenenamiento de memoria y contexto como un riesgo de seguridad de agente distinto porque el estado persistente puede influir en el comportamiento futuro mucho después de que la entrada original controlada por el atacante haya desaparecido. (genai.owasp.org)

La memoria, por lo tanto, debe tratarse como una base de datos de configuración, no como notas inofensivas.

Los controles requeridos incluyen:

• Separar la política de confianza de la memoria aprendida.
• Requerir revisión antes de escrituras persistentes.
• Registrar la fuente de cada elemento de memoria.
• Asignar fechas de caducidad a las memorias.
• Evitar que los secretos entren en la memoria.
• Admitir la reversión a un estado de memoria conocido y bueno.
• Escanear la memoria en busca de contenido similar a instrucciones.
• Probar el comportamiento con la memoria deshabilitada.
• Mantener memoria separada para cada repositorio, usuario y entorno.
• No permitir que el contenido de repositorio no confiable escriba memoria global.

Categoría de Amenaza Cinco: Riesgo de la Cadena de Suministro

Los agentes de codificación autónomos expanden el riesgo de la cadena de suministro de software en cinco direcciones.

Paquetes y scripts de instalación

Un agente puede instalar una dependencia maliciosa después de leer una instrucción envenenada. Los scripts del ciclo de vida de los paquetes pueden ejecutarse inmediatamente y pueden acceder a credenciales locales.

El compromiso de Nx en 2025 mostró cómo un token de publicación robado permitió a paquetes maliciosos escanear sistemas de usuarios, interactuar con herramientas locales de inteligencia artificial y cargar datos recolectados a repositorios públicos. Nx informó que los paquetes maliciosos estuvieron disponibles durante aproximadamente cuatro horas. (nx.dev)

Habilidades y extensiones del agente

Las habilidades del agente a menudo contienen instrucciones, scripts, definiciones de herramientas y requisitos de acceso. La auditoría de Snyk de 2026 de 3.984 habilidades en dos ecosistemas de habilidades públicas reportó niveles significativos de contenido inseguro y malicioso. Estas cifras son resultados de escaneo en lugar de brechas confirmadas, pero demuestran que los mercados de habilidades del agente deben tratarse como registros de software no confiables, no como tiendas de aplicaciones. (snyk.io)

Extensiones del entorno de desarrollo

Las extensiones pueden acceder al código fuente, archivos, terminales, credenciales y servicios de red. Una extensión maliciosa o comprometida puede atacar directamente al desarrollador o alterar el comportamiento del agente.

Cachés de compilación

Las cachés de compilación pueden cruzar fronteras de confianza. Un flujo de trabajo de bajo privilegio puede escribir un artefacto de caché que un flujo de trabajo de lanzamiento de mayor privilegio consume más tarde. Esto crea una ruta desde el procesamiento de incidencias hasta el robo de credenciales, incluso cuando el flujo de trabajo original no tiene acceso directo a los secretos de lanzamiento.

Modelos, prompts y definiciones de herramientas

Una actualización del modelo o un cambio en el prompt pueden alterar la forma en que el agente interpreta las instrucciones. Una actualización de la herramienta puede introducir un nuevo permiso predeterminado o cambiar la forma en que se analizan los comandos.

Cada despliegue de agente en producción debe versionar y aprobar:

• Identificador del modelo.
• Instrucciones del sistema.
• Instrucciones del desarrollador.
• Definiciones de herramientas.
• Reglas de política.
• Imagen del contenedor.
• Archivo de bloqueo de dependencias (lockfile).
• Política de red.
• Configuración de secretos.
• Esquema de memoria.
• Suite de evaluación.

Incidentes y Divulgaciones Notables de 2025 y 2026

La siguiente lista distingue incidentes operativos, avisos de seguridad y divulgaciones de investigación controladas.

El episodio de Replit fue descrito públicamente a través de informes de usuarios y respuesta ejecutiva en lugar de un aviso de seguridad convencional. Replit posteriormente enfatizó la separación de desarrollo y producción, las instantáneas (snapshots), las reversiones (rollbacks) y las restricciones en el acceso del agente a las bases de datos de producción. (fastcompany.com)

El incidente de Cline es particularmente importante porque demuestra la composición en cada categoría principal de este modelo de amenazas: inyección de prompts, ejecución de herramientas, envenenamiento de caché, robo de secretos, compromiso de la cadena de suministro e instalación automática en sistemas de desarrolladores posteriores. El aviso de Cline confirma la publicación no autorizada del paquete, mientras que la línea de tiempo del investigador describe el flujo de trabajo del agente y la cadena de ataque de caché precedentes. (github.com)

Evaluación de los Principales Patrones de Control

Ningún control único es suficiente. Las mejores implementaciones combinan varias capas independientes.

Sandboxes de capacidades

Los sandboxes se encuentran entre los controles más valiosos porque reducen el radio de acción incluso cuando el agente se comporta de manera maliciosa. Anthropic describe los sandboxes de procesos, las máquinas virtuales, los límites del sistema de archivos y los controles de salida (egress) como la forma principal de contener el comportamiento autónomo. (anthropic.com)

Sin embargo, los sandboxes deben tratarse como límites de seguridad de software. La vulnerabilidad de Codex demostró que un error en la lógica de configuración de rutas podría socavar el límite de espacio de trabajo previsto. (github.com)

Un sandbox robusto debe incluir:

• Una máquina virtual desechable o un contenedor endurecido.
• Sin acceso al directorio personal del desarrollador.
• Sin acceso a claves de shell seguro o credenciales de línea de comandos en la nube.
• Un espacio de trabajo dedicado montado en una ruta conocida.
• Acceso de solo lectura a la imagen base.
• Sin modo de contenedor privilegiado.
• Creación limitada de procesos.
• Cuotas de CPU, memoria, disco y tiempo de ejecución.
• Sin acceso a redes de producción.
• Destrucción automática después de la tarea.
• Una instantánea o artefacto del espacio de trabajo final para su revisión.

Motores de políticas

Un motor de políticas debe situarse entre el modelo y la herramienta. No debe depender del modelo para que se autorregule.

En lugar de permitir que el agente emita comandos de shell arbitrarios, exponga acciones tipificadas como:

• Leer archivo dentro del espacio de trabajo.
• Escribir archivo dentro del espacio de trabajo.
• Ejecutar comando de prueba aprobado.
• Instalar una dependencia de un registro aprobado.
• Crear una rama.
• Abrir una solicitud de extracción (pull request).
• Solicitar aprobación de despliegue.

El motor de políticas debe validar independientemente:

• La identidad del usuario.
• El repositorio.
• La ruta de destino.
• El comando o la herramienta.
• La clasificación de datos.
• El destino.
• El efecto secundario esperado.
• El estado de aprobación.
• El presupuesto restante de la sesión.

Ejecución reproducible de herramientas

La reproducibilidad a menudo se trata como una característica de calidad de compilación, pero también es un control de seguridad.

Para cada ejecución del agente, registrar:

• La versión exacta del modelo.
• La versión exacta del agente.
• Las versiones exactas de las herramientas.
• El resumen de la imagen del contenedor.
• El archivo de bloqueo de dependencias (lockfile).
• La confirmación (commit) del repositorio.
• La política de red.
• La versión de la política.
• La secuencia de llamadas a herramientas.
• Los hashes de los artefactos resultantes.

El Marco de Desarrollo de Software Seguro del NIST enfatiza los entornos de desarrollo seguros y la recopilación de datos de procedencia para los componentes de software. (csrc.nist.gov)

No uses valores mutables como:

• Última versión del paquete.
• Etiquetas de contenedor no fijadas.
• Scripts remotos no revisados.
• Definiciones de herramientas flotantes.
• Nombres de ramas no verificados.
• Cachés compartidas entre niveles de privilegio.

Redacción y intermediación de secretos

La redacción de secretos debe operar en múltiples puntos:

1. Antes de que el contenido entre en el contexto del modelo.
2. Antes de que se envíen los argumentos de la herramienta.
3. Antes de que se devuelva la salida de la herramienta.
4. Antes de que se almacenen los registros.
5. Antes de que se confirmen (commit) los archivos.
6. Antes de que las solicitudes de red salgan del ejecutor.
7. Antes de que se creen comentarios, incidencias y solicitudes de extracción (pull requests).

Un intermediario de secretos dedicado es más fuerte que las variables de entorno. El agente pide al intermediario que realice una operación estrechamente definida, como descargar un paquete privado, sin recibir la credencial en bruto.

Filtrado de salida (Egress filtering)

El acceso a la red debe denegarse por defecto.

Un proxy de salida (egress) práctico debe registrar:

• Dominio y dirección de destino.
• Método de solicitud.
• Tamaño de la solicitud.
• Tamaño de la respuesta.
• Identidad de la solicitud.
• Herramienta que inició la solicitud.
• Si había datos sensibles presentes.
• Si el destino fue aprobado.
• Si la solicitud ocurrió durante una acción sensible a la aprobación.

La arquitectura de flujo de trabajo agéntico de GitHub utiliza un firewall dedicado, una pasarela de Protocolo de Contexto del Modelo (Model Context Protocol) de confianza y un proxy de autenticación de modelo aislado. (github.blog)

Los controles de salida (egress) también deben tener en cuenta los canales indirectos. Una solicitud a un servicio de control de código fuente de confianza aún puede crear una incidencia o solicitud de extracción (pull request) maliciosa que contenga datos robados. Por lo tanto, los controles de red deben combinarse con reglas de salida segura y escaneo de contenido.

Arquitectura de Referencia Recomendada

Una implementación segura de codificación autónoma debe contener estas capas:

1. Capa de ingesta de contexto

Esta capa recopila archivos de repositorio, incidencias, resultados de pruebas y salida de herramientas. Debe etiquetar cada elemento por:

• Origen.
• Nivel de confianza.
• Autor.
• Marca de tiempo.
• Repositorio.
• Clasificación de datos.
• Si contiene contenido ejecutable.
• Si contiene instrucciones.

2. Separación de instrucciones y datos

El agente debe recibir una declaración explícita de que el contenido del repositorio, la salida de las herramientas, las páginas web y el texto de las incidencias son datos, a menos que se autorice por separado.

El sistema debe preservar el origen de cada pieza de contexto en lugar de aplanar todo en un único prompt indiferenciado.

3. Punto de aplicación de políticas

Cada llamada a una herramienta debe pasar por un motor de políticas que compruebe:

• Identidad.
• Capacidad.
• Objetivo.
• Argumentos.
• Sensibilidad de los datos.
• Destino de red.
• Requisitos de aprobación.
• Presupuesto de recursos.

4. Intermediario de capacidades

El agente recibe capacidades temporales en lugar de credenciales amplias. El intermediario debe emitir el permiso más pequeño necesario para el paso actual y revocarlo después.

5. Entorno de ejecución aislado

El agente se ejecuta en un entorno desechable con:

• Sin conectividad de producción.
• Sin montajes de credenciales de desarrollador.
• Sin acceso a repositorios no relacionados.
• Ámbito del sistema de archivos restringido.
• Límites de recursos estrictos.
• Imagen base inmutable.

6. Pasarela de herramientas

Se accede a las herramientas externas a través de una pasarela que realiza:

• Verificación de identidad de la herramienta.
• Validación de argumentos.
• Limitación de velocidad.
• Filtrado de salida.
• Comprobaciones de permisos.
• Registro de auditoría.
• Aislamiento de credenciales.

7. Proxy de salida (Egress proxy)

Toda la comunicación externa pasa a través de un proxy controlado. El acceso directo a la red desde el agente debe bloquearse.

8. Preparación de salida segura

El agente debe producir:

• Un parche.
• Una rama.
• Una solicitud de cambio.
• Una propuesta de despliegue.
• Un candidato a paquete.

No debe fusionar, desplegar, publicar o alterar directamente el estado de producción.

9. Revisión y promoción independientes

Un proceso separado revisa la salida propuesta utilizando:

• Escaneo de secretos.
• Análisis de seguridad estático.
• Análisis de dependencias.
• Comprobaciones de licencia y procedencia.
• Resultados de pruebas.
• Validación de políticas.
• Revisión humana para cambios de alto impacto.

El agente en la nube de GitHub sigue un patrón similar al crear solicitudes de extracción (pull requests) en borrador, restringir el acceso a las ramas, requerir revisión humana, limitar la ejecución de flujos de trabajo y proporcionar registros de sesión. (docs.github.com)

Listas de Verificación de Mitigación Accionables

Antes de habilitar un agente

• Crear una entrada de inventario para el agente.
• Identificar al propietario del agente y su propósito comercial.
• Documentar cada herramienta, conector y servicio externo.
• Documentar cada credencial a la que el agente puede acceder.
• Confirmar que las credenciales de producción están ausentes.
• Ejecutar el agente en un entorno desechable.
• Deshabilitar la instalación automática de paquetes a menos que se apruebe explícitamente.
• Deshabilitar el acceso a la red sin restricciones.
• Fijar (pin) el modelo, el agente, las herramientas, las dependencias y la imagen del contenedor.
• Proteger los archivos de instrucciones del agente y los archivos de configuración con reglas de propiedad de código.
• Definir qué acciones requieren aprobación humana.
• Definir una duración máxima de sesión y un costo.
• Crear un plan de reversión.

Antes de permitir el acceso al repositorio

• Clasificar el repositorio como público, interno, confidencial o altamente restringido.
• Revisar toda la configuración del agente controlada por el repositorio.
• Tratar los archivos README, el contenido de incidencias, los comentarios y la salida de pruebas como no confiables.
• Deshabilitar la ejecución automática de hooks y comandos del espacio de trabajo.
• Escanear dependencias y scripts de instalación.
• Usar un espacio de trabajo limpio y aislado.
• Prevenir el acceso a repositorios no relacionados.
• Verificar que no existan secretos en el espacio de trabajo o en los registros de compilación.
• Probar con texto de incidencia malicioso y documentación envenenada.
• Registrar el commit del repositorio y el hash de configuración del agente.

Antes de permitir el uso de herramientas

• Reemplazar el acceso arbitrario a shell con operaciones tipificadas siempre que sea posible.
• Usar una lista blanca para herramientas y destinos.
• Validar rutas después de la canonicalización.
• Rechazar escapes de enlaces simbólicos.
• Evitar que las herramientas modifiquen sus propios archivos de política.
• Evitar que el agente cambie su propio modo de aprobación.
• Requerir confirmación antes de un acceso a la red que incluya datos sensibles.
• Registrar cada llamada a la herramienta y su resultado.
• Establecer límites en el tamaño de archivos, tiempo de comandos, volumen de red y uso de tokens.
• Revisar las descripciones y permisos del servidor del Protocolo de Contexto del Modelo (Model Context Protocol).
• Rechazar definiciones de herramientas sin firmar o no verificadas.

Antes de permitir la publicación o el despliegue de código

• Requerir una identidad separada para el agente y el iniciador humano.
• Requerir revisión humana antes de la fusión (merge).
• Requerir aprobación independiente antes del despliegue.
• Usar credenciales de publicación de corta duración.
• Usar publicación de confianza o identidad de carga de trabajo en lugar de tokens de larga duración.
• Requerir firmas y procedencia de artefactos.
• Escanear en busca de secretos y dependencias maliciosas.
• Compilar desde un entorno limpio sin cachés mutables compartidas.
• Verificar que el artefacto coincide con el origen revisado.
• Mantener un proceso rápido de reversión de paquetes o extensiones.
• Probar la restauración de copias de seguridad e instantáneas.

Durante la respuesta a incidentes

• Terminar la sesión del agente afectado.
• Aislar el ejecutor o la estación de trabajo.
• Revocar todas las credenciales disponibles para el agente.
• Revocar credenciales disponibles para herramientas y conectores.
• Preservar los registros de sesión, herramienta, red y control de código fuente.
• Inspeccionar confirmaciones (commits), incidencias, solicitudes de extracción (pull requests), comentarios y publicaciones de paquetes.
• Inspeccionar cachés y scripts de instalación.
• Comparar artefactos publicados con la fuente de confianza.
• Buscar destinos de salida no autorizados.
• Revisar la memoria persistente y los archivos de configuración.
• Notificar a los proveedores de repositorio, registro de paquetes y herramientas.
• Rotar las credenciales nuevamente después del análisis forense si pudieron haber sido expuestas.
• Registrar si algún dato salió del entorno aprobado.

Acuerdos de Nivel de Servicio de Seguridad Propuestos

Estos son objetivos de despliegue propuestos, no estándares universales de la industria. Las organizaciones deben ajustarlos a su tolerancia al riesgo.

Para entornos altamente sensibles, el acuerdo de nivel de servicio más importante debe ser cero exfiltraciones de ruta crítica exitosas, en lugar de una tasa de detección promedio. Un solo robo exitoso de un token de lanzamiento puede ser más dañino que miles de intentos bloqueados inofensivos.

Artefactos de Auditoría Que Cada Despliegue Debe Producir

Una implementación madura debería poder responder, a posteriori:

• ¿Quién inició el agente?
• ¿Qué identidades de usuario y servicio estuvieron involucradas?
• ¿Qué repositorio y commit se utilizaron?
• ¿Qué versión del modelo y del agente se ejecutó?
• ¿Qué instrucciones estaban activas?
• ¿Qué contenido externo entró en el contexto?
• ¿Qué herramientas estaban disponibles?
• ¿Qué herramientas fueron realmente llamadas?
• ¿Qué argumentos se enviaron?
• ¿Qué archivos se leyeron o cambiaron?
• ¿A qué destinos de red se contactó?
• ¿Qué credenciales se solicitaron?
• ¿Qué políticas permitieron o denegaron cada acción?
• ¿Qué aprobaciones humanas se obtuvieron?
• ¿Qué artefacto se produjo?
• ¿Qué artefacto se publicó?
• ¿Cuál fue la disposición final?

Mantén al menos estos artefactos:

1. Registro de inventario del agente
2. Modelo de amenazas y diagrama de flujo de datos
3. Manifiesto de capacidades y permisos
4. Inventario de herramientas y conectores
5. Registro de versión de modelo, prompt y política
6. Imagen de contenedor y lista de materiales de dependencias
7. Política de red y registro de salida (egress)
8. Informe de exposición y redacción de secretos
9. Traza de sesión y llamadas a herramientas
10. Registro de aprobación humana
11. Evaluación de seguridad e informe de equipo rojo
12. Procedencia de lanzamiento y firma de artefactos
13. Procedencia de memoria y registro de reversión
14. Respuesta a incidentes y prueba de restauración
15. Aviso de seguridad del proveedor y registro de parches

Los registros deben ser a prueba de manipulaciones, con control de acceso y conservarse según la sensibilidad de los datos. Las sesiones de desarrollo ordinarias pueden requerir noventa días de retención, mientras que las sesiones que acceden a sistemas de lanzamiento, datos regulados o repositorios de alto valor pueden requerir un año o más.

OpenAI describe un monitoreo interno que revisa las interacciones de los agentes de codificación, las llamadas a herramientas y el comportamiento potencialmente sospechoso, mientras que GitHub enfatiza los registros de sesión, los commits firmados, la atribución y los registros de auditoría. Estos patrones respaldan un principio más amplio: el comportamiento del agente debe ser observable independientemente de la propia explicación del agente sobre lo que hizo. (openai.com)

El Primer Paso Práctico

El mejor primer paso no es desplegar un agente contra un repositorio de producción.

En su lugar:

1. Crear un repositorio de prueba desechable.
2. Asignar al agente una tarea de solo lectura.
3. Ejecutarlo dentro de un sandbox nuevo.
4. Desactivar el acceso a las credenciales de desarrollador.
5. Bloquear todo el tráfico de red excepto el del proveedor del modelo.
6. Añadir una incidencia, instrucción de README, descripción de herramienta y archivo de configuración deliberadamente maliciosos.
7. Registrar cada intento de acceso a archivos, llamada a herramienta, comando y solicitud de red.
8. Utilizar los resultados para crear su primer manifiesto de permisos y acuerdo de nivel de servicio de seguridad.

Si el agente no puede completar de forma segura una tarea de solo lectura bajo esas condiciones, no está listo para el acceso de escritura, la automatización de lanzamientos o los sistemas de producción.

Conclusión

Los agentes de codificación autónomos deben protegerse como sistemas de automatización no confiables y con identidad, no como herramientas de desarrollador ordinarias.

La pregunta de seguridad decisiva no es:

“¿Seguirá el modelo las instrucciones correctas?”

Es:

“¿Qué sucede si el modelo sigue la instrucción equivocada mientras posee permisos reales?”

La inyección de prompts, la explotación de herramientas, el robo de secretos, el envenenamiento de datos y el compromiso de la cadena de suministro son diferentes puntos de entrada a la misma falla subyacente: se permite que un agente cruce demasiadas fronteras de confianza sin una aplicación independiente.

Los incidentes de 2025 y 2026 muestran que los controles más efectivos son arquitectónicos:

• Mantener a los agentes alejados de los secretos.
• Usar sandboxes de capacidades desechables.
• Aplicar políticas fuera del modelo.
• Separar el desarrollo de la producción.
• Tratar la configuración y la memoria como superficies de ataque ejecutables.
• Usar salida controlada (egress).
• Eliminar las cachés compartidas de los flujos de trabajo de lanzamiento privilegiados.
• Fijar (pin) y verificar cada herramienta y artefacto.
• Organizar todas las escrituras por etapas.
• Requerir aprobación independiente para acciones irreversibles.
• Preservar registros de auditoría detallados y a prueba de manipulaciones.

La autonomía puede ser útil y segura, pero solo cuando el sistema está diseñado para que un agente confundido, manipulado o comprometido tenga autoridad limitada, alcance limitado, tiempo limitado y un modo de fallo claramente recuperable.