Agentes de código en el endpoint: visibilidad, control y auditoría para gobernar el nuevo riesgo del desarrollo

En los últimos meses ha aparecido un actor silencioso dentro de muchos equipos de ingeniería: no es un humano, ni un servicio tradicional, sino un asistente de programación capaz de leer archivos, ejecutar comandos en la shell, llamar a APIs externas y conectar con integraciones de terceros. Estas “agentes” de código —un ejemplo destacado es Claude Code de Anthropic— se ejecutan en la máquina del desarrollador con los mismos permisos que éste y, por tanto, operan fuera del perímetro de las herramientas de seguridad que tradicionalmente protegen la red o los gateways.

Este cambio no es trivial. Muchos controles de seguridad están pensados para ver y actuar cuando el tráfico sale del dispositivo: los SIEM, los monitores de red y los gateways inspeccionan comunicaciones en tránsito. Pero un agente local ya puede haber leído secretos, modificado ficheros o ejecutado una secuencia de comandos antes de que cualquier paquete cruce la red. La acción ocurre en el endpoint y, salvo que esa capa también esté observada, queda fuera de alcance. Para entender mejor por qué esto importa conviene recordar que estos agentes suelen “vivir del sistema”: reutilizan binarios y credenciales ya presentes en la máquina en lugar de traer los suyos, lo que dificulta su detección con las técnicas clásicas de filtrado. Organizaciones y equipos de seguridad llevan tiempo alertando sobre esta forma de operar, que en la terminología de seguridad se conoce como “living off the land”; para referencias técnicas útiles puede consultarse la documentación de MITRE ATT&CK sobre técnicas relacionadas: MITRE ATT&CK – LOLBins / System Binary Proxy Execution.

¿Qué puede hacerse cuando un agente ejecuta comandos con los permisos de un desarrollador y no deja rastro en los logs que el equipo de seguridad ya recoge? Una solución que aparece en este contexto es colocar una capa de confianza y control directamente en el dispositivo del desarrollador, junto al propio agente. Beyond Identity ha llamado a este componente Ceros: una “capa de confianza” que se instala en el endpoint y que pretende ofrecer tres cosas clave: visibilidad en tiempo real, bloqueo o mitigación de acciones no autorizadas, y un rastro de auditoría criptográficamente verificable.

La propuesta de Ceros es pragmática: la adopción de controles en el entorno del desarrollador debe ser invisible para no romper la productividad. Desde la perspectiva del equipo de ingeniería la interacción con el agente debería seguir igual, pero detrás de la escena Ceros captura el contexto del dispositivo (versión del sistema, estado de protección, cifrado de disco, Secure Boot y otros indicadores de postura), recoge la genealogía de procesos que inició la sesión y lo ata a una identidad humana verificada, firmando las evidencias con claves vinculadas al hardware del equipo.

En la consola administrativa de Ceros aparece por primera vez para muchos equipos algo que antes era una caja negra: las conversaciones completas entre cada desarrollador y su agente, y —lo más relevante— las llamadas a herramientas que se ejecutaron durante esas conversaciones. Cuando una petición aparentemente inocua desencadena la ejecución de un comando de shell o la lectura de un fichero, la plataforma lo muestra con el comando exacto, sus argumentos y la salida resultante. Esta visibilidad de las “herramientas invocadas” transforma la percepción del riesgo: deja de ser una sospecha y pasa a ser evidencia concreta.

Junto a las sesiones, Ceros expone los conectores externos que los agentes han usado: los llamados MCP servers, que son los puentes hacia bases de datos, APIs internas, plataformas de mensajería o servicios en la nube. En muchas organizaciones la lista de integraciones que los desarrolladores han conectado por su cuenta supera lo que los equipos de seguridad creían permitido; la falta de revisión de esos caminos de acceso constituye un vector de riesgo en sí mismo.

Visibilidad sin gobernanza es sólo detección. Por eso Ceros incorpora una capa de políticas que se evalúan en tiempo real antes de que una acción se ejecute. Entre las opciones que pagan dividendos rápidamente están las reglas de allowlist para MCP servers: sólo se permite la conexión a servidores aprobados y el resto se bloquea en el punto de origen. También se pueden crear controles por herramienta: limitar el uso de Bash, permitir lecturas de ficheros solo dentro de rutas de proyecto o inspeccionar los argumentos de una llamada para permitirla o denegarla. Asimismo, las políticas de postura de dispositivo exigen condiciones mínimas —por ejemplo cifrado de disco o protección endpoint activa— para permitir que el agente se ejecute; y, si el estado del equipo cambia durante una sesión, la plataforma puede volver a evaluar y actuar según lo definido.

Desde el punto de vista de cumplimiento, la diferencia más relevante es el rastro de pruebas. El registro de actividad que genera Ceros no es un archivo de log que un administrador pueda editar a posteriori: cada entrada se firma con una clave ligada al hardware antes de salir del dispositivo, creando una cadena de evidencia con sello temporal y atribución humana. Para equipos que deben responder a auditorías bajo marcos como SOC 2, FedRAMP, HIPAA o PCI-DSS, disponer de registros inmutables y con contexto forense —identidad del usuario, árbol de procesos, firmas binarias, postura del dispositivo y detalle de las acciones— facilita demostrar controles efectivos. Si desea revisar fuentes oficiales sobre requisitos de auditoría y control, puede consultar los recursos del AICPA sobre SOC, la web de FedRAMP, la documentación de la HHS sobre HIPAA y la página del PCI Security Standards Council.

Además de bloquear o permitir, la plataforma permite administrar de forma centralizada qué integraciones están disponibles: los administradores pueden desplegar servidores MCP aprobados a los agentes de todos los desarrolladores desde una consola, evitando configuraciones manuales y garantizando que los equipos trabajen sólo con las herramientas oficiales. Combinada con la allowlist, esta capacidad convierte la gobernanza en algo operativo y automático, sin añadir fricción al flujo de trabajo del desarrollador.

Todo esto se resume en un panel que ofrece una visión agregada del riesgo asociado a agentes en toda la organización: cuántos dispositivos están enrolados, qué instancias del agente están activas y dónde existen brechas de adopción que podrían indicar que agentes se ejecutan fuera del control. Para equipos de seguridad que deben priorizar esfuerzos, esa telemetría es el punto de partida para tomar decisiones informadas.

No se trata de demonizar a las herramientas de asistencia: los asistentes de programación ofrecen productividad real. El reto es que su modelo de operación exige repensar la arquitectura de seguridad: si la acción se produce en el endpoint, allí es donde debe medirse y gobernarse. La recomendación práctica para los equipos que ya usan o planean desplegar agentes es comenzar por la visibilidad: solo cuando se sabe qué acciones se ejecutan y por quién es posible diseñar políticas que mitiguen riesgo sin frenar a los desarrolladores.

Si quiere conocer más sobre las soluciones del fabricante mencionadas en este artículo, puede visitar la web de Beyond Identity en beyondidentity.ai, y la página de despliegue del agente en agent.beyondidentity.com. Para entender el fenómeno más amplio de agentes y extensiones de modelos, la industria también está moviéndose hacia marcos y prácticas de seguridad adaptadas a estos nuevos flujos; OpenAI ha documentado enfoques de extensibilidad en su blog, y análisis de técnicas de abuso y mitigación aparecen en recursos como los de MITRE.

En resumen, los asistentes de programación en el endpoint son una nueva capa de riesgo y oportunidad. La estrategia efectiva pasa por instrumentar el dispositivo: registrar, controlar y firmar lo que sucede en el momento en que sucede, no reconstruiéndolo después. Solo así los equipos de seguridad podrán integrar estos agentes dentro de controles auditables y adecuados a los requisitos regulatorios y de negocio.