Nas duas últimas partes desta série, abordei Como o Modelo de Protocolo de Contexto se alinha a uma API de Carga e depois desmantelou os servidores MCP de frete que foram enviados em 2026. Ambas terminaram com a mesma questão em aberto, pelo que esta parte responde diretamente a ela: assim que um agente puder reservar frete real, como é que se impede que reserve a coisa errada para a pessoa errada? A segurança é onde um servidor MCP de frete deixa de parecer um brinquedo de programador e começa a parecer um sistema que move dinheiro e camiões.
Eu corro isto a partir da sede de um mercado que expõe uma API, pelo que o meu viés é prático em vez de académico. As ameaças abaixo são as que efetivamente modelamos quando decidimos que ferramenta um agente pode chamar sem um humano a supervisionar.
Porque um servidor de frete aumenta as apostas
Um servidor genérico MCP que lê o seu calendário vaza informações quando falha. Um servidor de frete que reserva uma carga faz algo mais dispendioso. Uma má chamada pode despachar um camião para o pátio errado, alterar um consignatário numa expedição ativa, cancelar uma reserva em que um cliente está a contar, ou emitir um conhecimento de embarque que nunca deveria ter saído da conta. Estes não são erros de exposição de dados. São dinheiro e mercadorias físicas a moverem-se com uma instrução que ninguém digitou.
Essa diferença reformula o problema inteiro. Com um assistente de chat, o pior cenário é uma resposta embaraçosa. Com o frete, o pior cenário tem uma fatura de frete anexada e um envio em algum lugar onde não deveria estar. Portanto, a questão nunca é "este servidor é seguro" no abstrato. É "quais ações específicas um agente pode tomar, e qual o custo de cada uma se der errado."
Os dois modos de falha que valem a pena perder o sono
A maioria do risco de MCP em 2026 reduz-se a dois padrões, e o transporte de mercadorias agrava ambos.
Injeção de prompt é o antigo problema da web com roupa nova. Um agente lê texto de algum lugar que não controla totalmente, uma nota de remessa, um PDF, o corpo de um e-mail, e esse texto contém uma instrução que o modelo obedece. No frete, o texto envenenado chega por canais legítimos o dia todo: um comentário de reserva, uma descrição alfandegária, uma atualização de status de uma transportadora. Se a sua ferramenta de reserva confia no que quer que o modelo lhe passe, uma frase escondida numa nota de entrega pode tornar-se um cancelamento real.
O **envenenamento de ferramentas** é mais subtil e específico para MCP. O protocolo permite que um servidor descreva as suas próprias ferramentas, e o agente lê essas descrições para decidir o que chamar. Um servidor malicioso ou comprometido pode escrever uma descrição que diz silenciosamente ao modelo para exfiltrar uma chave de API ou reencaminhar uma remessa, e o utilizador nunca vê esse texto. A Anthropic e investigadores independentes passaram o início de 2026 a documentar variantes disto, e a lição para o transporte de mercadorias é clara: a camada de descrição é executável, por isso trate uma descrição de ferramenta de terceiros com a mesma suspeita que trataria código de terceiros.
Ler vs. escrever: a linha que deve decidir a sua autenticação
A decisão de segurança mais útil que tomei foi deixar de pensar no "servidor MCP" como um único limite de confiança e dividi-lo com base no que cada ferramenta faz no mundo.
O que pode ficar aberto
Citar uma rota, listar a capacidade, calcular uma estimativa de trânsito, procurar um código de porto. Nada disto muda nada. Permitir que um agente os alcance com pouco ou nenhum atrito é o objetivo principal, e é aí que reside o valor diário. Um leitor que queira comparar três rotas não deve ter de criar um token para o fazer. Em todos os servidores da análise, os mais sérios mantiveram as ferramentas de cotação e referência com baixo atrito exatamente por esta razão.
O que deve ser controlado
Reservar, cancelar, alterar um consignatário, editar uma morada, obter um documento, qualquer coisa que toque numa fatura. Cada um destes ações escreve para o mundo real e cada uma necessita de uma chamada autenticada, autorizada e auditável por trás. A regra que seguimos é simples de enunciar e mais difícil de impor: uma ferramenta de leitura pode ser aberta, uma ferramenta de escrita nunca o é.
OAuth 2.1 e PKCE, sem uma chave de longa duração num ficheiro de configuração
A especificação de autorização do MCP adotou o OAuth 2.1 para servidores remotos, e essa escolha tem um peso real para o setor de transporte de mercadorias. Uma chave de API estática colada num ficheiro de configuração serve para um programador individual a executar um servidor sobre stdio na sua própria máquina. É o modelo errado no momento em que o servidor é acessível via HTTP e um agente atua em nome de um utilizador nomeado dentro de uma conta partilhada.
Três propriedades fazem o trabalho pesado. Tokens com âmbito definido significam que um token criado para cotação não pode reservar. Tokens de curta duração significam que uma credencial vazada expira por conta própria em vez de existir para sempre num registo. Tokens revogáveis significam que, quando algo parece errado, o acesso é cortado em segundos em vez de substituir uma chave partilhada de que todos dependem. O OAuth 2.1 também exige PKCE no fluxo de "código de autorização", o que fecha a lacuna de interceção que implementações mais antigas do OAuth deixaram aberta. Nada disto é exótico. É o mesmo reforço de segurança que qualquer API de pagamentos sofreu, aplicado ao momento em que um agente diz "reserve".
Eis a forma da fronteira que aplicamos, escrita como a tabela que gostaria que todos os servidores de frete publicassem.
| Ação do agente | Lê ou escreve | Autenticação necessária | Se correr mal |
| Obter um orçamento | Ler | Chave aberta ou básica | Chamada perdida, sem danos |
| Verificar capacidade, trânsito, rastreamento | Ler | Chave aberta ou básica | Resposta desatualizada, na pior das hipóteses |
| Agendar uma Expedição | Escreva | Token OAuth com escopo, passo de confirmação | Custo real, camião real |
| Cancelar ou remarcar | Escreva | Token com âmbito, chave de idempotência | Slot perdido, penalização |
| Alterar consignatário ou morada | Escreva | Token com escopo, confirmação humana | Entrega errada, fraude |
| Pedir um conhecimento de embarque ou fatura | Ler sensível | Token com âmbito, verificação por documento | Fuga de dados e documentos |
O padrão nessa tabela é a decisão real do produto. As leituras ficam à esquerda e permanecem baratas. As escritas ficam à direita e ganham o seu atrito.
O problema da instância exposta
Uma quantidade surpreendente de risco de MCP não é nada inteligente. É um servidor que foi concebido para ser executado localmente, exposto à internet sem autenticação, porque enviá-lo dessa forma era mais fácil. O protocolo suporta dois transportes. Um servidor stdio corre como um processo local que o cliente lança, o que o mantém na sua máquina e fora da rede. Um servidor HTTP hospedado é alcançável por qualquer coisa que consiga encontrar o seu URL.
Para um servidor utilitário de apenas leitura, a exposição HTTP é, na sua maioria, inofensiva. Para um com ferramentas de reserva, é o jogo inteiro. Se as suas ferramentas de escrita forem acessíveis através de HTTP público, a autenticação não é uma funcionalidade que adiciona mais tarde, é a coisa que se encontra entre um estranho e a sua fila de despacho. A nossa regra é que as ferramentas de reserva e de documentos nunca são servidas através de um ponto final HTTP não autenticado, ponto final. Em caso de dúvida, um servidor com capacidade de escrita deve apresentar por defeito `stdio` e lançamento local, e só progredir para HTTP hospedado quando o fluxo OAuth acima estiver implementado.
Defender a camada de descrição contra envenenamento de ferramentas
Como as descrições das ferramentas orientam o modelo, elas merecem os mesmos controlos que o código que implementa. Três hábitos cobrem a maior parte da exposição.
- Afine e rever os servidores a que se liga. Um agente ligado a um conjunto selecionado de servidores conhecidos é um alvo menor do que um que instala o que quer que um registo ofereça. Trate um novo servidor como uma nova dependência, pois é isso que ele é.
- Mantenha um humano em cada escrita. Uma etapa de confirmação antes de reservar, cancelar ou alterar um destinatário transforma uma instrução silenciosamente injetada num pedido visível que o utilizador pode recusar. É o controlo mais barato com o maior retorno.
- Valide na API, não no prompt. O servidor deve verificar novamente cada parâmetro que recebe em relação às permissões reais da conta e ao estado real da reserva, em vez de confiar que o modelo montou uma chamada sensata. O modelo propõe, a API decide.
O que um servidor de marketplace tem de impor para que um único transportador possa saltar
Um servidor de portador único atua sempre na sua própria rede, pelo que o seu raio de impacto é de um operador. Um servidor de mercado cita e reserva através de múltiplos portadores em nome de muitos utilizadores, o que muda a tarefa de segurança de duas formas.
Primeiro, o âmbito tem de ser por utilizador e por transportadora, não por servidor. Um token que permite a um agente reservar com uma transportadora não deve atingir silenciosamente outra, e o agente de um cliente nunca deve ver os documentos de outro cliente. Segundo, o registo de auditoria é mais importante, porque quando um agente reserva num mercado, é necessário responder a "qual utilizador, qual token, qual transportadora, a que horas" para cada escrita. Tratamos esse registo como parte do produto, não como uma reflexão tardia, uma vez que é o que nos permite revogar seletivamente em vez de desligar tudo para todos.
Um checklist prático antes de expor a reserva
- Divida as ferramentas por leitura e escrita, e anote a divisão num local onde o agente e a sua equipa possam ver.
- Mantenha as ferramentas de citação e referência de baixo atrito para que o valor diário sobreviva.
- Coloque cada escrita atrás de um token OAuth 2.1 com âmbito definido, de curta duração e revogável com PKCE.
- Exigir um passo de confirmação em alterações de reserva, cancelamento, destinatário e endereço.
- Revalidar todos os parâmetros na API contra as permissões reais e o estado real do envio.
- Nunca sirva ferramentas de escrita sobre HTTP não autenticado e defina servidores capazes de escrita para stdio local por defeito.
- Afine os servidores a que o seu agente se liga e reveja novos, tal como código novo.
- Registe cada escrita com o utilizador, token, transportadora e hora, e ensaie a revogação antes de precisar dela.
Nenhum destes é exclusivo da inteligência artificial. São os controlos que o transporte de mercadorias e os pagamentos já utilizam, direcionados para o novo local onde uma instrução pode originar-se. O agente é um novo interlocutor, não um novo conjunto de regras.
Perguntas frequentes
É seguro deixar um agente de IA reservar frete?
Sim, quando a reserva é feita após uma chamada autenticada e autorizada com uma etapa de confirmação, e quando o servidor reexamina todos os parâmetros em vez de confiar no modelo. A versão insegura é uma ferramenta de escrita aberta sem intervenção humana. Trate a reserva como qualquer outra ação que movimente dinheiro e o agente torna-se outro chamador autenticado.
Porquê usar OAuth 2.1 em vez de uma chave API simples?
Uma chave estática tende a ter um ciclo de vida longo, um âmbito amplo e é difícil de revogar sem afetar todos os que a partilham. O OAuth 2.1 oferece tokens com âmbito limitado, de curta duração e revogáveis, e exige PKCE no fluxo de autorização. Para um servidor stdio local, uma chave é aceitável, mas qualquer coisa acessível através de HTTP que possa escrever deve usar o modelo OAuth.
O que é a "tool poisoning" no MCP?
O envenenamento de ferramentas ocorre quando a descrição de uma ferramenta num servidor, que o agente lê para decidir o que chamar, contém instruções ocultas que levam o modelo a realizar ações prejudiciais, como divulgar uma chave ou reencaminhar um envio. Como a descrição influencia o comportamento, defende-a da mesma forma que defende o código: fixe servidores de confiança, mantenha um humano nas escritas e valide na API.
Um servidor MCP de frete deve rodar como stdio ou via HTTP hospedado?
Um servidor utilitário somente de leitura é aceitável via HTTP hospedado. Um servidor com ferramentas de reserva ou documentos deve usar stdio local por defeito e só mudar para HTTP hospedado após a implementação de OAuth com âmbito, porque um ponto de extremidade de escrita exposto sem autenticação é alcançável por qualquer pessoa que encontre o URL.
Isto fecha o ciclo que esta série abriu. Se não leu as partes anteriores, o Protocolo Introdutório explica como uma API de frete se torna um conjunto de ferramentas, e o desmontagem mostra onde os servidores enviados traçaram estas linhas na prática.