A primeira conexão MCP em produção deve ser tratada como uma revisão de segurança, porque o agente passa a operar com dados, permissões e efeitos reais. Antes de liberar o acesso, a equipe precisa limitar o escopo, testar ações perigosas, registrar chamadas e definir como interromper a integração.
Na segunda-feira, às 9h12, Rafael conectou o agente interno ao servidor MCP da empresa. Engenheiro de plataforma, pai de uma menina pequena e ainda com o café esfriando ao lado do teclado, ele esperava encerrar uma tarefa rotineira antes da reunião diária. O indicador ficou verde. O agente listou as ferramentas disponíveis e encontrou uma capaz de consultar pedidos no ambiente de produção.
Este é um cenário composto, criado para ilustrar um risco comum. Rafael digitou uma pergunta simples sobre uma compra de teste. A resposta trouxe o pedido correto, mas também exibiu nome, endereço e histórico de atendimento de uma pessoa que não fazia parte do teste. Naquele instante, a conexão deixou de ser uma integração técnica. Tornou-se um incidente em potencial.
O sinal verde confirma conexão, não segurança
Uma conexão MCP funcional responde a uma pergunta estreita: cliente e servidor conseguem se comunicar? Ela não informa se o agente recebeu permissões excessivas, se os argumentos são validados ou se uma chamada aparentemente inofensiva pode alcançar dados sensíveis.
O problema cresce porque agentes não usam ferramentas como uma interface convencional. Eles interpretam contexto, escolhem chamadas e combinam resultados. Uma função chamada `buscar_pedido` pode aceitar um identificador livre, retornar campos demais ou permitir consultas amplas quando recebe um argumento incompleto. Cada decisão razoável isoladamente pode formar um caminho que ninguém planejou.
Rafael cancelou a demonstração. Se aquela resposta chegasse ao canal compartilhado da equipe, dados pessoais ficariam expostos para pessoas sem necessidade de acesso. Se o agente também tivesse uma ferramenta de escrita, a mesma falha de escopo poderia alterar um pedido real. O lançamento interno previsto para aquela manhã ficou em dúvida.
A pergunta certa naquele momento não era “o MCP está funcionando?”. Era “o que este agente consegue ver, decidir e mudar quando algo sai do roteiro?”.
Revise o caminho inteiro da chamada
A análise precisa começar pela identidade usada na conexão. Uma credencial administrativa transforma qualquer erro de interpretação em um erro administrativo. O agente deve receber uma identidade própria, com acesso somente às operações necessárias para aquele fluxo.
Depois, examine cada ferramenta como uma superfície de ataque:
- Quais dados ela aceita e devolve?
- Há validação de formato, tamanho e escopo?
- Uma consulta pode atravessar contas, equipes ou ambientes?
- A ferramenta escreve, exclui, publica ou envia alguma coisa?
- Existe confirmação humana antes de uma ação difícil de desfazer?
- Instruções vindas de documentos ou páginas podem influenciar sua execução?
Os registros também precisam contar a história completa. Isso inclui a identidade do agente, a ferramenta escolhida, os argumentos enviados, o resultado, a decisão de autorização e o horário. Segredos e dados pessoais devem ser mascarados. Sem esse rastro, a equipe sabe que algo aconteceu, mas não consegue reconstruir por quê.
A aquisição da Virtue AI pela Fortinet reforça a direção do mercado: agentes autônomos, modelos e ferramentas MCP estão entrando no escopo de red teaming automatizado, proteção em tempo de execução e monitoramento de segurança. A conexão MCP precisa ser observada durante a operação, pois uma revisão feita uma única vez não acompanha mudanças de modelo, ferramenta, permissão ou dado.
Teste o que o agente nunca deveria conseguir fazer
Rafael reuniu a engenheira de segurança e a responsável pelo sistema de pedidos. Em vez de repetir a consulta que já funcionara, os três montaram testes para os finais ruins.
Tentaram pedir pedidos de outra conta, omitir identificadores, inserir instruções no campo de busca e induzir o agente a chamar uma ferramenta fora do fluxo aprovado. Também verificaram o comportamento diante de respostas incompletas e erros do servidor. O objetivo era encontrar o ponto em que uma entrada maliciosa, ambígua ou simplesmente estranha ultrapassava a autorização esperada.
O teste mais útil falhou: sem um identificador válido, a ferramenta devolvia os registros recentes. Era uma conveniência criada para uso manual, quando uma pessoa autorizada operava a interface. Para um agente, aquilo virava uma porta lateral.
A equipe alterou a ferramenta para rejeitar consultas sem escopo explícito, reduziu os campos retornados e separou leitura de escrita. Ações com efeito externo passaram a exigir aprovação humana. A credencial também ganhou permissões menores e um mecanismo simples de revogação.
Com pouco tempo restante antes da decisão sobre o lançamento, Rafael repetiu os testes. Desta vez, a tentativa de consulta ampla terminou em bloqueio registrado, sem dados na resposta.
Produção começa quando as consequências ficam reais
A liberação segura não termina no primeiro teste aprovado. Defina alertas para volume incomum, chamadas fora do padrão, repetição de erros e tentativas de acessar ferramentas negadas. Estabeleça quem pode revogar a credencial, desativar uma ferramenta e investigar uma sequência suspeita.
Mantenha ambientes separados. Dados sintéticos e ferramentas sem efeitos externos ajudam nos primeiros testes, mas não substituem a revisão das permissões reais. Antes de ampliar o acesso, registre o comportamento esperado e os finais proibidos. Esse inventário dá à equipe algo concreto para validar sempre que o servidor, o modelo ou o fluxo mudar.
Na tarde daquela segunda-feira, Rafael não tinha uma integração mais impressionante para mostrar. Tinha algo melhor: uma conexão com limites verificáveis, registros úteis e uma forma de interromper o acesso. O café já estava frio, mas o canal da equipe continuava sem dados pessoais e o agente só conseguia executar o trabalho que recebera.
Comentários
Ainda não há comentários.