Como mudanças na lista de ferramentas MCP alteram uma sessão ativa

Uma sessão MCP ativa não deve herdar confiança para ferramentas que não existiam quando você a aprovou. A descoberta de ferramentas parece uma parte inofensiva da infraestrutura até que um agente possa chamar uma ação recém-disponível com o mesmo embalo da conversa e as mesmas credenciais por trás dela. Nesse momento, a superfície de ação mudou, mesmo que ninguém tenha alterado o prompt.

Já vi engenheiros aprovarem uma execução de programação para trabalhar em um repositório e deixá-la ativa enquanto um conector ganhava uma ação de implantação ou de abertura de ticket. A defesa habitual é: «o agente tinha apenas as ferramentas de que precisava». Essa frase deixa de ser verdadeira no instante em que a lista muda. Um agente de longa duração merece menos confiança casual que um processo curto de linha de comando, não mais.

A regra que uso é simples: compare o inventário de ferramentas sempre que ele mudar, classifique a mudança de autoridade e inicie uma nova execução de agente quando a mudança adicionar ou alterar de forma relevante uma superfície de ação. Não transforme isso em um projeto de linguagem de políticas. O objetivo é preservar uma decisão humana que ainda tenha o mesmo significado de quando você a tomou.

Uma lista de ferramentas é um inventário de autoridade

Uma lista de ferramentas MCP não é um menu. É o conjunto de operações que um agente pode propor e, dependendo do cliente, invocar. Cada item combina nome, descrição, esquema de entrada e um comportamento que muitas vezes alcança um serviço que o modelo não consegue inspecionar diretamente.

A especificação do Model Context Protocol descreve ferramentas como funções controladas pelo modelo e expostas por um servidor. Essa formulação importa. Um cliente pode apresentar descrições ao modelo, mas a descrição não é uma fronteira de segurança. O esquema e o comportamento no servidor definem o que a chamada pode fazer.

Ao revisar um inventário, faço cinco perguntas sobre cada ferramenta:

• Quais dados essa chamada pode ler?
• Que estado essa chamada pode alterar?
• Para onde sua saída pode ir?
• Qual credencial ou host ela usa?
• Seus argumentos podem ampliar o escopo além do que o nome sugere?

Uma ferramenta chamada get_build_status pode ser somente leitura e limitada. Uma ferramenta chamada request pode ler, gravar e enviar dados para qualquer lugar permitido por sua credencial. Os nomes fazem a primeira parecer fácil de aprovar e a segunda, fácil de subestimar.

Com frequência, a área confunde descoberta de ferramentas com permissão. A descoberta informa ao agente o que está disponível. A permissão decide se o agente pode usar aquilo. Se você misturar essas ideias, uma atualização no meio da sessão vira uma mudança de permissão sem revisão.

Ferramentas adicionadas merecem a revisão mais rigorosa

Uma ferramenta adicionada exige uma nova execução quando cria uma nova rota para dados, comandos ou uma parte externa. Isso vale mesmo quando a nova ferramenta parece relacionada ao trabalho que o agente já realiza.

Suponha que um agente comece com repo_search, read_issue e create_branch. No meio da sessão, o servidor adiciona post_comment. Alguém pode chamar isso de pequena extensão porque o agente já lê issues. Não é algo pequeno. Ler uma issue é uma consulta privada. Publicar um comentário envia texto gerado pelo modelo para pessoas que podem agir com base nele e pode revelar detalhes da conversa ou do espaço de trabalho.

Por padrão, trate estas adições como relevantes:

• Qualquer ação que grave, exclua, implante, publique ou envie uma mensagem.
• Qualquer ferramenta de requisição geral cujo destino venha de um argumento.
• Qualquer ação de shell ou SSH, inclusive uma anunciada como diagnóstico.
• Qualquer ação que leia um novo repositório, conta, host ou categoria de dados.
• Qualquer ação que use uma credencial de escopo mais amplo que as ferramentas existentes.

Uma nova ação de leitura também pode exigir reinício. Às vezes, engenheiros reservam a preocupação para gravações e acabam expondo uma ferramenta de exportação que lê registros de clientes, logs de build ou segredos armazenados em configurações. A exfiltração começa por uma leitura.

Há exceções limitadas. Adicionar um segundo nome para uma operação fixa já aprovada pode permanecer na execução se você verificou que ele alcança o mesmo serviço com os mesmos argumentos e a mesma credencial. Isso é incomum o bastante para que eu não conceda a exceção com base em uma nota de versão.

Ferramentas removidas são um sinal, não uma revogação completa

Uma ferramenta removida deve levar você a verificar o cliente, pois o desaparecimento em uma lista nova não prova que o agente em execução perdeu o acesso a ela. O servidor pode ter alterado a lista anunciada enquanto o cliente ainda mantém uma lista anterior na memória. Outro cliente pode atualizar imediatamente. Não é seguro deduzir o comportamento apenas pela remoção.

Isso importa na revisão de incidentes. Uma equipe vê delete_environment removida do servidor, presume que o perigo passou e mantém uma sessão antiga ativa. Se esse cliente já resolveu a definição da ferramenta, ele ainda pode tentar a chamada. O servidor deve rejeitá-la se a implementação removeu o manipulador, mas descoberta anunciada e execução real são coisas separadas. Verifique ambas.

Pause o agente e registre o inventário anterior e o posterior. Depois, teste a ação removida em um ambiente que não seja de produção, se o servidor for seu, ou encerre a sessão se não for. Não pergunte ao modelo se ele ainda tem a ferramenta. A resposta de um modelo descreve seu contexto de forma pouco confiável e jamais deve resolver uma questão de autorização.

A remoção também traz uma consequência mais comum: uma mudança de nome de ferramenta pode aparecer primeiro como uma remoção e uma adição. Por isso você compara definições em vez de contar nomes.

Mudanças de nome exigem prova de equivalência

Uma mudança de nome pode ser cosmética, mas também pode esconder um contrato mais amplo. Os casos perigosos costumam surgir em manutenção comum: search_logs vira query_logs, um esquema ganha um campo opcional project e o serviço passa a aceitar identificadores de projetos remotos. O nome mal mudou. A autoridade mudou.

Crie um registro de comparação simples o bastante para usar sob pressão. Para cada ferramenta antiga e nova, registre nome, descrição, JSON Schema, anotações declaradas de somente leitura ou destrutivas, quando existirem, endpoint ou comando de apoio, identidade da credencial e efeitos conhecidos. JSON Schema não revela todo o comportamento do servidor, portanto trate-o como evidência, não como resposta completa.

Este é um formato mínimo útil para o inventário:

{
  "name": "query_logs",
  "inputSchema": {
    "type": "object",
    "properties": {
      "project": {"type": "string"},
      "query": {"type": "string"}
    },
    "required": ["query"]
  },
  "destination": "logs-api",
  "credential": "logs-read",
  "effects": ["read"]
}

Isso não evita uma requisição malformada. Evita que uma pessoa revisora aceite uma mudança de nome sem perceber o novo seletor project, que pode transformar uma consulta local em recuperação entre projetos.

Se os registros antigo e novo diferem em destino, credencial, efeitos ou escopo de argumentos, trate como uma capacidade adicionada e reinicie. Se você não consegue identificar o comportamento de apoio, reinicie de qualquer forma. «Provavelmente é igual» não é resultado de uma revisão.

Mudanças no esquema importam mais que descrições

Uma ferramenta pode manter o nome e ainda se tornar mais perigosa. Os esquemas de entrada mostram onde isso costuma acontecer: novos campos de URL, caminhos, seletores de conta, strings de comando em formato livre, listas de destinatários e sinalizadores opcionais que mudam o modo de execução.

Considere uma ferramenta que começa com esta entrada:

{
  "type": "object",
  "properties": {"issue_id": {"type": "string"}},
  "required": ["issue_id"]
}

Mais tarde, ela aceita include_private_notes ou destination_url. O primeiro campo muda o que a ferramenta lê. O segundo cria uma rota de saída. Nenhum deles precisa de um novo nome chamativo para exigir outra fronteira de aprovação.

Descrições também mudam. Um servidor pode alterar «Obter detalhes da versão» para «Obter e atualizar detalhes da versão» sem mudar o esquema. Leia as descrições, mas não pare aí. Pergunte ao responsável qual manipulador é executado, qual identidade ele usa e se faz requisições de saída. Uma boa resposta cita um comando, endpoint ou conta de serviço. «É apenas um auxiliar interno» não informa nada útil.

A especificação MCP permite metadados e anotações de ferramentas, mas o suporte a anotações e a interpretação pelos clientes variam. Use-os como rótulos úteis. Não baseie decisões de aprovação em um rótulo como somente leitura quando a chamada chega, no fim, a um endpoint de propósito geral.

Uma nova execução cria uma fronteira que você consegue explicar

Uma nova execução é necessária quando a aprovação teria um significado diferente após a mudança no inventário. Essa fronteira tem valor prático: interrompe o processo atual, torna a próxima aprovação atribuível a um executável conhecido e separa, nos seus registros, o conjunto antigo de chamadas do novo.

O processo é curto:

1. Interrompa novas chamadas de ferramentas quando o inventário mudar de modo inesperado.
2. Salve os inventários antigo e novo, incluindo esquemas e a versão do servidor, se disponível.
3. Marque cada diferença como removida, renomeada, modificada ou adicionada.
4. Reinicie se alguma diferença ampliar o acesso a dados, os efeitos, o escopo do destino ou o escopo da credencial.
5. Aprove a nova execução apenas depois de conseguir descrever em linguagem simples sua superfície de ação permitida.

Não reinicie apenas para cumprir um ritual. Reinicie porque isso invalida uma aprovação anterior específica. Essa diferença mantém a regra útil. Uma equipe que reinicia a cada correção ortográfica começará a ignorar a regra. Uma equipe que reinicia diante de nova autoridade aprenderá a reconhecê-la.

A autorização por sessão funciona bem quando vincula a aprovação a um processo que termina. Sallyport segue esse modelo ao mostrar a autoridade de assinatura de código de um novo processo de agente e manter essa aprovação durante a execução, até o processo encerrar. Um inventário alterado ainda é motivo para encerrar esse processo se as ações que ele pode solicitar se ampliaram.

A aprovação por chamada cobre as ações que devem continuar exigindo cuidado

A aprovação por chamada serve para ações cujas consequências são grandes demais para ficarem escondidas em uma aprovação ampla de sessão. Use-a para mudanças em produção, operações destrutivas, mensagens públicas, ações financeiras e requisições que podem enviar dados sensíveis para um destino escolhido em tempo de execução.

Algumas equipes tentam resolver isso com uma longa lista de permissões em condições de linguagem natural. A abordagem continua popular porque promete menos interrupções. Também entrega às pessoas revisoras um mecanismo frágil de regras que elas precisam entender enquanto um agente está ativo. Uma estrutura mais segura usa poucas escolhas visíveis: negar enquanto o cofre estiver bloqueado, aprovar um processo conhecido para uma execução limitada ou exigir um clique para um uso específico de credencial.

A configuração de chave por chamada do Sallyport se encaixa nesta última categoria. O agente pode pedir para realizar a ação, mas nunca recebe a chave de API ou SSH em texto simples. Isso reduz o vazamento de credenciais, enquanto a pessoa ainda decide se essa requisição específica deve sair da máquina.

Não marque todas as ações como por chamada. Se uma leitura inofensiva gerar prompts repetidos, as pessoas aprovarão sem ler. Coloque atrito onde ele preserva o discernimento.

O registro de auditoria precisa resistir a uma mudança contestada

Uma trilha de auditoria deve responder qual processo de agente foi executado, o que ele chamou e se alguém alterou a superfície disponível antes da chamada. Registrar apenas a requisição final não basta quando a disputa é: «Essa ferramenta estava disponível quando aprovamos a sessão?»

Mantenha um instantâneo do inventário com um resumo estável ao lado dos registros de sessão. Registre o nome da ferramenta, o esquema canônico, a identidade do servidor e o momento em que seu cliente a observou. Quando houver uma mudança, preserve ambos os instantâneos e a decisão de classificação. Você não precisa de um banco de dados elaborado para começar. Um registro assinado ou à prova de adulteração com a resposta bruta de descoberta é muito melhor que uma reconstrução oral na manhã seguinte.

Sallyport registra execuções de agentes no diário Sessions e chamadas individuais no diário Activity, ambos projetados a partir de um único log de auditoria criptografado e encadeado por hash. Seu comando sp audit verify verifica essa cadeia offline sobre texto cifrado, sem precisar de uma chave do cofre. Isso é evidência útil depois de uma mudança, mas apenas se a equipe também registrar qual inventário a execução viu.

Uma cadeia de hash detecta alterações em entradas mantidas. Ela não prova que você registrou todos os eventos de todos os componentes e não informa se uma aprovação foi sensata. Mantenha essas alegações separadas. Revisões de segurança ficam mais fracas quando as pessoas pedem que um mecanismo responda perguntas que ele não consegue responder.

Trate a descoberta dinâmica como um evento de implantação

Se seu servidor MCP pode alterar ferramentas sem reiniciar o cliente, a equipe efetivamente implantou uma nova superfície de ação em um canal de controle ativo. Dê a esse evento a disciplina de uma versão: identifique o responsável, revise a diferença, declare a autoridade esperada e deixe um registro que uma pessoa investigadora possa ler depois.

A primeira ação prática é adicionar um instantâneo do inventário ao início de cada execução de agente e compará-lo antes que qualquer atualização entre em vigor. Não espere um incidente dramático. A mudança discreta de nome que adiciona um campo de destino opcional é exatamente o tipo de alteração que passa despercebida por pessoas ocupadas e competentes.