MCP vs CLI: Qué sucede cuando tu agente de IA no puede encontrar el conector

Cuando un agente de IA necesita actuar en una máquina, la ruta limpia es el Model Context Protocol (MCP). Un servidor MCP expone un conjunto definido de herramientas, el agente las llama, y puedes razonar sobre lo que se le permite hacer porque la lista es corta y está escrita. Luego, el agente necesita algo sin conector, como un sistema interno de tickets o una aplicación de línea de negocio que nadie ha tocado desde 2012, y la historia cambia. Un agente decidido a terminar su tarea busca otra puerta, y esa puerta casi siempre es la línea de comandos.

La mayoría de la conversación en línea sobre MCP vs CLI se centra en los costos de tokens, OAuth y el manejo de credenciales, que son temas válidos para debatir. Muy poco se pregunta qué ejecutará realmente el endpoint una vez que el agente se salga del camino MCP, y esa es la parte que terminan gestionando los administradores de TI.

MCP vs CLI

Los dos enfoques otorgan al agente cantidades muy diferentes de poder. Con MCP, el agente recibe una lista definida de herramientas y nada más. Con una CLI, el agente controla un shell, y un shell tiene todos los derechos del usuario conectado. El modo código, el patrón más reciente que se explica a continuación, se comporta como el lado CLI de esa línea cuando se ejecuta en un escritorio gestionado, porque el agente escribe su propio programa y la máquina lo ejecuta.

Esa diferencia explica por qué a los desarrolladores les gusta la CLI (consume pocos tokens y los agentes están familiarizados con herramientas como git y docker) y por qué a los equipos de seguridad les gusta MCP (una lista corta es más fácil de auditar y OAuth ofrece autenticación centralizada). Ambos bandos tienen razón. Lo que ninguno resuelve es qué impide que un agent ejecute algo que nadie aprobó una vez que sale de la lista de herramientas.

Los agentes recurren a la CLI

Imagina que un desarrollador le pide a un agente que extraiga datos de ese sistema de tickets. Sin un conector, el agente escribe un script, descarga un binario auxiliar y encadena algunos comandos, y nadie aprobó nada porque la gobernanza de tu MCP nunca lo vio. El agente salió completamente del mundo MCP. Es como una película de atracos en la que el equipo de seguridad pasó meses en la bóveda principal mientras el equipo entraba por la zona de carga; el equipo aquí es un software bien intencionado, y la zona de carga está igual de abierta.

La solución alternativa también es silenciosa, porque un registro MCP no tiene constancia de un PowerShell command que el agente ejecutó por sí mismo.

La ejecución de código con MCP coloca código escrito por agentes en sus endpoints

El propio MCP está cambiando. En lugar de llamar a una herramienta a la vez y enviar cada resultado de nuevo al modelo, los agentes están pasando al modo código: el agente escribe un pequeño programa que llama a las herramientas MCP, filtra y combina lo que recibe, y ejecuta todo. Anthropic describió este patrón en su blog de ingeniería, y la ventaja es fácil de ver, ya que un script puede hacer veinte llamadas a herramientas sin pasar cada resultado por el modelo. Ahorra tokens y hace a los agentes más capaces, por lo que está ganando terreno.

También coloca código real, creado por el agente, en sus endpoints. La ejecución de código con MCP cambia la cuestión de control de qué herramientas puede llamar el agente a qué programas ejecutará el endpoint, y un programa es tan confiable como quien lo haya escrito. Algunas configuraciones ejecutan ese código en una sandbox, y una sandbox ayuda mucho. Sin embargo, un escritorio Windows o Mac gestionado generalmente no es una sandbox, y si la máquina ejecuta cualquier cosa que reciba, su lista de herramientas aprobadas es solo una sugerencia, porque el código del agente puede evitar el servidor MCP tan fácilmente como pasar a través de él.

Lo que un shell malicioso o script de agente puede hacer con permisos de administrador local

El daño depende de los derechos que el agente esté tomando prestados. Bajo un administrador local, el modo de reserva CLI tiene control total de la máquina, por lo que puede instalar software o desactivar protecciones sin pedir permiso. El agente de un usuario estándar aún puede ejecutar un archivo que nadie revisó, ya sea por error propio o porque una inyección de comandos oculta en un documento que leyó se lo indicó.

Aplicar límites donde se ejecuta el código

Muchos equipos intentan controlar al agente con indicaciones del sistema, límites y políticas en lenguaje sencillo. Eso ayuda, pero se aplica en el lado de la IA, y un agente puede confundirse o ser manipulado. La opción confiable es imponer límites donde se ejecuta el código, para que el resultado sea seguro sin importar lo que intente el agente. El endpoint es la parte del stack que TI ya posee, y es donde PolicyPak funciona.

Cómo PolicyPak maneja MCP vs CLI: mínimo privilegio y listas de permitidos

PolicyPak aborda el problema desde dos direcciones, y la primera es el principio de menor privilegio. PolicyPak Least Privilege Manager elimina los derechos de administrador local de los usuarios y otorga derechos de administrador solo a las aplicaciones y tareas específicas que los necesitan, tanto en Windows como en Mac. Un agente que recurre a la CLI bajo un usuario estándar no puede instalar controladores ni manipular herramientas de seguridad, y las excepciones que otorgaste permanecen limitadas a las aplicaciones que nombraste.

El segundo es la lista de permitidos. PolicyPak SecureRun funciona a partir de la propiedad del archivo: los ejecutables introducidos por usuarios estándar, o por un agente que actúa como tal, no se ejecutan a menos que una cuenta de confianza los posea, como su herramienta de despliegue de software o un administrador. Eso es importante para el modo código. Cuando un agente escribe un script o deja un binario auxiliar, SecureRun no confía en el archivo y lo bloquea, lo que también explica por qué funciona como prevención de ransomware con un solo clic. Obtiene una lista de permitidos general sin mantenimiento hash por hash y sin eliminar las herramientas que ya usa.

Los agentes pueden seguir usando MCP donde exista un conector. Donde no haya ninguno, la opción de reserva CLI se ejecuta en una máquina donde el usuario no tiene derechos de administrador y el archivo que el agente acaba de crear no tiene un propietario confiable, y eso sigue siendo así cuando la ejecución de código con MCP es lo habitual.