MCP vs CLI: O que acontece quando seu agente de IA não encontra o conector

Quando um agente de IA precisa agir em uma máquina, o caminho limpo é o Model Context Protocol (MCP). Um servidor MCP expõe um conjunto definido de ferramentas, o agente as chama, e você pode raciocinar sobre o que ele está autorizado a fazer porque a lista é curta e escrita. Então o agente precisa de algo sem conector, como um sistema interno de tickets ou um aplicativo de linha de negócios que ninguém mexe desde 2012, e a história muda. Um agente determinado a concluir sua tarefa procura outra porta, e essa porta quase sempre é a linha de comando.

A maior parte da conversa online sobre MCP vs CLI gira em torno dos custos de tokens, OAuth e o manuseio de credenciais, que são assuntos justos para discutir. Pouco se questiona o que o endpoint realmente executará quando o agente sair do caminho MCP, e essa é a parte que os administradores de TI acabam assumindo.

MCP vs CLI

As duas abordagens dão ao agente quantidades muito diferentes de poder. Com MCP, o agente recebe uma lista definida de ferramentas e nada mais. Com uma CLI, o agente controla um shell, e um shell possui todos os direitos do usuário conectado. O modo código, o padrão mais recente abordado abaixo, comporta-se como o lado CLI dessa linha quando é executado em um desktop gerenciado, porque o agente escreve seu próprio programa e a máquina o executa.

Essa diferença explica por que os desenvolvedores gostam da CLI (ela consome poucos tokens e os agentes estão familiarizados com ferramentas como git e docker) e por que as equipes de segurança preferem MCP (uma lista curta é mais fácil de auditar e o OAuth oferece autenticação centralizada). Ambos os lados têm razão. O que nenhum resolve é o que impede um agent de executar algo que ninguém aprovou uma vez que sai da lista de ferramentas.

Os agentes recorrem à CLI

Imagine que um desenvolvedor peça a um agente para extrair dados desse sistema de tickets. Sem um conector, o agente escreve um script, baixa um binário auxiliar e junta alguns comandos, e ninguém aprovou nada porque a governança do seu MCP nunca viu isso. O agente saiu completamente do mundo MCP. É como um filme de assalto em que a equipe de segurança passou meses na cofre principal enquanto a equipe entrou pelo doca de carga; a equipe aqui é um software bem-intencionado, e o doca está igualmente aberta.

O fallback também é silencioso, porque um log MCP não registra um PowerShell command que o agente executou por conta própria.

A execução de código com MCP coloca código escrito por agentes nos seus endpoints

O próprio MCP está mudando. Em vez de chamar uma ferramenta de cada vez e encaminhar cada resultado de volta ao modelo, os agentes estão passando para o modo código: o agente escreve um pequeno programa que chama as ferramentas MCP, filtra e combina o que retorna, e executa tudo. A Anthropic descreveu esse padrão em seu blog de engenharia, e a vantagem é fácil de ver, pois um script pode fazer vinte chamadas de ferramentas sem passar cada resultado pelo modelo. Isso economiza tokens e torna os agentes mais capazes, por isso está ganhando espaço.

Também coloca código real, criado pelo agente, nos seus endpoints. A execução de código com MCP desloca a questão de controle de quais ferramentas o agente pode chamar para quais programas o endpoint executará, e um programa é tão confiável quanto quem o escreveu. Algumas configurações executam esse código em uma sandbox, e uma sandbox ajuda muito. Um desktop Windows ou Mac gerenciado geralmente não é uma sandbox, e se a máquina executa qualquer coisa que recebe, sua lista de ferramentas aprovadas é apenas uma sugestão, porque o código do agente pode contornar o servidor MCP tão facilmente quanto passá-lo.

O que um shell rogue ou script de agente pode fazer com privilégios de administrador local

O dano depende dos direitos que o agente está emprestando. Sob um administrador local, o fallback CLI tem controle total da máquina, podendo instalar software ou desativar proteções sem pedir permissão. O agente de um usuário padrão ainda pode executar um executável que ninguém revisou, seja por erro próprio ou porque uma injeção de prompt escondida em um documento que leu o instruiu a fazer isso.

Aplicar limites onde o código é executado

Muitas equipes tentam controlar o próprio agente com prompts do sistema, limites e políticas em linguagem simples. Isso ajuda, mas ocorre no lado da IA, e um agente pode ficar confuso ou ser manipulado. A ação confiável é impor limites onde o código é executado, para que o resultado permaneça seguro, independentemente do que o agente tente. O endpoint é a parte da pilha que o TI já possui, e é onde PolicyPak funciona.

Como o PolicyPak trata MCP vs CLI: menor privilégio e allowlisting

PolicyPak aborda o problema de duas direções, sendo a primeira o princípio do menor privilégio. O PolicyPak Least Privilege Manager remove direitos de administrador local dos usuários e concede direitos de administrador apenas às aplicações e tarefas específicas que precisam deles, no Windows e Mac. Um agente que recorre ao CLI sob um usuário padrão não pode instalar drivers nem manipular ferramentas de segurança, e as exceções que você concedeu permanecem limitadas aos aplicativos que você nomeou.

O segundo é a lista de permissões. PolicyPak SecureRun funciona com base na propriedade do arquivo: executáveis introduzidos por usuários padrão, ou por um agente atuando como tal, não são executados a menos que uma conta confiável os possua, como sua ferramenta de implantação de software ou um administrador. Isso é importante para o modo código. Quando um agente escreve um script ou deixa um binário auxiliar, o SecureRun não confia no arquivo e o bloqueia, o que também explica por que funciona como prevenção de ransomware com um clique. Você obtém uma lista de permissões geral sem manutenção hash por hash e sem remover as ferramentas que já usa.

Os agentes podem continuar usando MCP onde existir um conector. Onde não houver, o fallback CLI ocorre em uma máquina onde o usuário não tem direitos de administrador e o arquivo que o agente acabou de criar não tem um proprietário confiável, e isso permanece verdadeiro quando a execução de código com MCP é a norma.