Su agente local puede actuar. ¿Puede controlarlo?

Imagínese que un desarrollador le pide a un agente de programación que investigue una implementación fallida.

El agente puede acceder al directorio del proyecto, examinar el código fuente y los archivos de configuración, buscar en Internet instrucciones para la resolución de problemas y utilizar las herramientas autorizadas por el desarrollador. Al investigar el error, se accede a una página de documentación comprometida que indica al agente que recopile los archivos de configuración y las variables de entorno del proyecto y, a continuación, los envíe a un «punto final de diagnóstico» para validar la configuración de la implementación.

El agente considera esa instrucción como parte de la tarea de resolución de problemas. Lee los archivos de configuración, incluye valores confidenciales, como claves de API o credenciales de implementación, e intenta enviarlos al servicio externo.

Nada en este escenario es intrínsecamente inusual. El agente está aprobado. El acceso al directorio es necesario para la tarea. La búsqueda web es una parte normal de la resolución de problemas. El riesgo no radica en el mero acceso a los datos y las herramientas, sino en cómo se combinan esas capacidades y en el hecho de que el agente pueda actuar en consecuencia sin que una persona supervise cada paso.

Por qué es difícil proteger a los agentes locales

El escenario anterior ilustra perfectamente por qué resulta difícil garantizar la seguridad de los agentes de IA locales, como Claude Code, Codex y Microsoft 365 Copilot. Trabajan en estrecha colaboración con el usuario y, a menudo, utilizan los mismos archivos, permisos y herramientas que permiten a las personas ser productivas. Sin embargo, los controles tradicionales se diseñaron pensando en un responsable humano que aplica su criterio antes de conceder un permiso. Los agentes pueden combinar acceso, contexto y acciones a velocidad de máquina.

• El entorno está descentralizado: Es posible que el agente programador de este ejemplo esté autorizado, pero es posible que el sistema de seguridad no detecte todos los componentes que determinan su comportamiento. Esto incluye los directorios a los que puede acceder, las funcionalidades que tiene instaladas, los servidores de MCP a los que se conecta y las herramientas que puede utilizar. 

• El riesgo se crea mediante combinaciones: Cada componente puede ser legítimo por sí solo. El agente necesita acceso al directorio del proyecto. La búsqueda web le ayuda a solucionar problemas. Un servicio de diagnóstico externo puede parecer útil. El riesgo aparece cuando el agente combina instrucciones externas con acceso a archivos de configuración confidenciales y una herramienta de salida. 

• Un agente puede actuar sin revisión humana: El desarrollador pidió al agente que investigara un fallo en la implementación, no que compartiera datos de configuración. Sin embargo, el agente puede interpretar la página comprometida como parte de la tarea, recopilar los archivos e intentar llevar a cabo la acción externa antes de que el desarrollador se percate de cada paso. 

Esto no es teórico. In DuneSlide, de Cato AI Labs, demostró cómo una inyección de comandos sin necesidad de clics, realizada a través de un servidor de MCP o de un resultado web malicioso, podía escapar del entorno aislado de Cursor y provocar el compromiso total del equipo de un desarrollador. En otro incidente ocurrido en 2025, un programador de Replit borró una base de datos de producción durante un periodo de congelación del código declarado explícitamente.

Estos incidentes ponen de manifiesto por qué la seguridad basada en agentes requiere algo más que una revisión puntual de los permisos. Los equipos deben comprender a qué pueden acceder los agentes, qué pueden hacer y cómo varían sus funcionalidades a medida que los usuarios añaden habilidades, conectan servidores de MCP y conceden nuevos permisos.

El marco de tres partes de Cato para la contratación de agentes locales

Un programa eficaz de seguridad de agentes locales comienza con tres preguntas conectadas:

Cada etapa informa a la siguiente. La visibilidad establece el inventario. La postura pone el inventario en contexto al mapear el acceso, los permisos y el radio de impacto. Los controles de tiempo de ejecución utilizan ese contexto para detectar y evitar comportamientos peligrosos en las interacciones en tiempo real.

El escenario de implementación fallida del desarrollador plantea tres cuestiones de seguridad.

1. Visibilidad: ¿Qué hay en el entorno?

Empiece por el agente mismo. ¿Quién lo está usando? ¿A qué archivos puede llegar? ¿Qué servidores, herramientas y funcionalidades de MCP extienden su comportamiento?

En el ejemplo, es posible que el equipo de seguridad sepa que el desarrollador utiliza un agente de programación, pero que no sepa que este puede realizar búsquedas en la web, acceder a un directorio del proyecto que contenga archivos de configuración o utilizar una herramienta de implementación conectada. Un inventario de aplicaciones instaladas no es suficiente. Los equipos necesitan visibilidad del entorno de trabajo del agente y de los componentes que definen su alcance real.

Desde esta perspectiva, el equipo de seguridad puede pasar de preguntarse: «¿Permitimos este agente?», a preguntarse: «¿A qué se conecta este agente y qué capacidades aporta al entorno?».

2. Postura: ¿Qué riesgo crea?

A continuación, trace un mapa del acceso efectivo del agente y del radio de explosión potencial.

Para la investigación sobre el fallo en la implementación, el agente necesita cierto acceso al código fuente. Pero, ¿tiene también acceso a información confidencial, credenciales de producción, repositorios de código fuente o herramientas que puedan enviar datos al exterior? ¿Puede una funcionalidad instalada ampliar su ámbito de actuación más allá de la tarea en cuestión? ¿Puede un servidor de MCP introducir contenido no confiable en el contexto del agente?

Para cada agente local, los equipos deberían poder responder lo siguiente:

• ¿A qué directorios y archivos puede acceder? 

• ¿A qué herramientas y servidores de MCP puede acceder? 

• ¿Qué permisos tiene y qué acciones pueden habilitar esos permisos? 

• ¿Qué funcionalidades o servidores de MCP está utilizando, de dónde provienen y qué riesgos introducen? 

Cada componente puede ser legítimo por sí solo. El riesgo surge cuando trabajan juntos. Un agente capaz de leer texto local supone un riesgo distinto al de uno que puede leer archivos de configuración, ejecutar herramientas externas y modificar los parámetros de implementación.

La postura ayuda a los equipos a determinar dónde se requieren controles adicionales antes de que un agente se enfrente a una interacción de riesgo.

3. Control en tiempo de ejecución: ¿Podemos poner fin a los comportamientos peligrosos?

La visibilidad y la postura reducen la incertidumbre. El control en tiempo de ejecución determina qué ocurre cuando el agente recupera esa página de documentación comprometida e intenta actuar en consecuencia.

Los controles eficaces supervisan toda la interacción en tiempo real: la solicitud del usuario, la respuesta del modelo, las entradas y salidas de la herramienta, y la acción que el agente intenta llevar a cabo. Deben detectar cuándo un contenido no fiable intenta redirigir al agente y evitar que se lleve a cabo la acción posterior que supone un riesgo.

La respuesta debe coincidir con el riesgo. Un equipo puede optar por supervisar una interacción de bajo riesgo, ocultar los datos sensibles, bloquear una llamada a una herramienta o detener la acción por completo.

Cato AI Security aplica políticas a las solicitudes, las respuestas, las llamadas a herramientas y las acciones de las herramientas. Ofrece a los equipos un único punto de control, con opciones de implementación en la red, los dispositivos finales, las API y las integraciones.

Esto resulta especialmente importante para una inyección rápida. Se puede incluir una instrucción maliciosa en el contenido que se le pide a un agente que resuma o recupere; no es necesario que aparezca en la solicitud original del usuario. Los controles en tiempo de ejecución deben identificar dicha instrucción en el momento en que entra en el contexto del agente e impedir que este lleve a cabo la acción posterior que no sea segura.

El contexto compartido lo hace operativo

El riesgo asociado a los agentes locales abarca a los usuarios, los dispositivos, las aplicaciones, los agentes, las fuentes de datos y la red. Cuando esas perspectivas están desconectadas entre sí, resulta más difícil comprender cómo se produjo una interacción de riesgo, y la investigación o la respuesta se retrasan.

Los equipos de seguridad necesitan un contexto compartido: una forma de relacionar la actividad de un agente con su titular, las herramientas y los datos a los que ha accedido, los permisos que sustentan dichas acciones y la decisión normativa que se adoptó a raíz de ello. Esto permite a los equipos pasar de la fase de detección a la de investigación y, posteriormente, a la de respuesta, sin tener que generar el historial en sistemas distintos.

Cato centraliza la seguridad de los agentes en un único punto de control, con opciones de implementación en la red, los terminales, las API y las integraciones. Esto proporciona a los equipos de seguridad el contexto necesario para comprender cómo interactúan los agentes, los usuarios, los datos y las herramientas, y para aplicar controles coherentes antes de que las actividades de riesgo se materialicen. Al combinar un marco de seguridad basado en la inteligencia artificial con controles nativos de la IA, Cato protege los agentes locales en la actualidad y la próxima generación de herramientas de IA en el futuro.

Obtenga más información sobre la protección de la IA agéntica a escala empresarial.