MCP virou parte da Software Supply Chain. Sua empresa está olhando para isso?

Um coding agent moderno já não se limita a completar uma linha de código. Dependendo da configuração, ele pode ler o repositório, editar arquivos, executar comandos, consultar APIs, abrir issues, acessar bancos de dados, chamar ferramentas externas e instalar dependências.

Essa mudança altera a pergunta de segurança.

Antes, uma equipe de AppSec podia concentrar grande parte do controle em artefatos relativamente conhecidos: código, dependências, imagens, pipelines e repositórios. Com agentes conectados a tools, skills e servidores MCP, parte das decisões passa a ocorrer antes mesmo de o código chegar ao commit.

O problema deixa de ser apenas:

O código produzido pela IA é seguro?

E passa a incluir:

Podemos confiar nas ferramentas, instruções, permissões e integrações que ajudaram a produzir esse código?

Por que MCP entrou na conversa de AppSec

O Model Context Protocol (MCP) permite que aplicações e agentes se conectem a recursos e ferramentas externas por uma interface padronizada.

Na prática, isso pode aproximar o agente de sistemas como:

• Repositórios de código;
• Issue trackers;
• Bancos de dados;
• APIs internas;
• Serviços de cloud;
• Documentação;
• Sistemas de arquivos;
• Terminais e ferramentas de desenvolvimento.

Essa capacidade é útil justamente porque permite ao agente agir com mais contexto. O mesmo ganho, porém, aumenta o impacto de uma configuração insegura.

A própria especificação do MCP trata ferramentas como uma superfície que exige cautela. A documentação de segurança destaca riscos relacionados a autorização, roubo de tokens, confused deputy, redirecionamentos e confiança em integrações.

O risco já deixou de ser teórico

Uma pesquisa publicada pela Snyk em junho de 2026 analisou quase 10 mil ambientes de desenvolvimento. Dentro da amostra realizada, 50,8% dos desenvolvedores tinham pelo menos um MCP Server instalado.

Entre os desenvolvedores com MCP Servers, 1 em cada 7 apresentou pelo menos um finding de segurança.

Esse número deve ser lido corretamente: é uma pesquisa de fornecedor sobre a amostra observada pela própria Snyk, não uma estimativa universal de todo o mercado.

Ainda assim, o sinal é importante. MCP, coding agents e skills já estão presentes em ambientes reais em escala suficiente para que AppSec precise tratá-los como parte da superfície de desenvolvimento.

O NIST chegou a conclusão semelhante em outro contexto. Em seu relatório de 2026 sobre segurança de agentes de IA, o instituto registrou amplo consenso entre participantes de que agentes introduzem riscos específicos e que princípios tradicionais de cibersegurança continuam válidos, mas precisam ser adaptados ao modelo agentic.

Três superfícies que precisam ser governadas

Uma forma prática de organizar o problema é separar o risco em três perguntas.

1. O que o agente usa?

Antes de executar qualquer tarefa, o agente pode depender de:

• MCP Servers;
• Tools;
• Skills;
• Plugins;
• Modelos;
• Bibliotecas;
• Documentação;
• Serviços externos.

A organização precisa saber de onde esses elementos vieram, quem os aprovou, o que podem fazer e como serão atualizados.

Um MCP Server conhecido não deveria ser tratado como confiável para sempre apenas porque foi aprovado uma vez. Mudanças de versão, mantenedor, configuração ou backend podem alterar seu risco.

2. O que o agente pode fazer?

Permissão é uma das principais diferenças entre um assistente passivo e um agente.

Considere dois cenários:

1. 01Assistente restritolê código e sugere alteração
2. 02Revisão humanadesenvolvedor decide o que aplicar

Em outro cenário:

1. 01Agente autônomolê código e contexto
2. 02Ferramentasexecuta terminal e chama APIs
3. 03Dependênciasinstala componentes
4. 04Sistemasacessa cloud ou repositórios
5. 05Entregaabre PR e aciona pipeline

Os dois usam IA, mas o risco operacional é completamente diferente.

Quanto maior a autonomia, mais importantes ficam:

• Menor privilégio;
• Segregação de funções;
• Escopo de tokens;
• Expiração de credenciais;
• Aprovação humana;
• Trilha de auditoria;
• Limites de execução.

3. O que o agente gera?

Mesmo que ferramentas e permissões estejam controladas, o código produzido continua precisando passar pelos controles normais de engenharia.

Isso inclui:

• Revisão;
• SAST;
• SCA;
• Secret scanning;
• Testes;
• Análise de IaC quando aplicável;
• Políticas de pipeline;
• Validação de artefatos.

A adoção de agentes não elimina AppSec. Ela adiciona uma nova camada antes dos controles que já existiam.

Prompt injection muda de impacto quando o agente possui ferramentas

Prompt injection em um chatbot sem acesso a sistemas pode produzir uma resposta errada.

Em um agente conectado a ferramentas, a consequência pode ser maior.

Uma instrução maliciosa pode estar em:

• Documentação externa;
• Issue;
• Comentário;
• Página web;
• Descrição de tool;
• Arquivo dentro do próprio repositório;
• Contexto retornado por outra integração.

Se o agente interpreta a instrução como parte legítima da tarefa e possui permissão para agir, o problema deixa de ser exclusivamente de conteúdo e passa a envolver execução.

Por isso, segurança agentic não pode depender apenas de “um prompt melhor”. É necessário combinar limites técnicos de autorização, confiança de origem, validação de ações e observabilidade.

Dependências instaladas por agentes merecem o mesmo controle das humanas

Outro ponto de atenção é a instalação de software.

Um desenvolvedor pode escolher conscientemente uma biblioteca. Um agente pode recomendar ou instalar uma dependência como parte de uma tarefa maior.

Em ambos os casos, o pacote entra na mesma Software Supply Chain. Logo, as regras não deveriam depender de quem executou o comando.

1. 01Solicitaçãohumano ou agente pede uma dependência
2. 02Origemvalidar registry, namespace e identidade
3. 03Riscovulnerabilidade, malware, política e sinais de confiança
4. 04Instalaçãopermitir, bloquear, quarentenar ou revisar
5. 05Buildexecutar com identidade e permissões controladas
6. 06Evidênciaregistrar versão, origem e decisão

O controle precisa permanecer no ponto de ingestão e no pipeline, e não apenas na intenção do usuário ou do agente.

Um caso real: quando o MCP entra na Supply Chain

Em setembro de 2025, a Postmark reportou um pacote npm malicioso chamado postmark-mcp que se passava por uma integração legítima da Postmark.

O pacote aparentou ser legítimo durante 15 versões. Na versão 1.0.16, ele adicionou um backdoor que enviava secretamente cópias ocultas (BCC) dos e-mails para um servidor externo.

O caso mostra que o risco não está apenas no comportamento do agente ou nas permissões concedidas a uma ferramenta. O próprio MCP Server utilizado pelo agente pode se tornar um componente comprometido da cadeia de software.

Para equipes de AppSec, isso amplia a pergunta de "quais vulnerabilidades existem nesse componente?" para "de onde veio esse componente, quem o publicou, o que ele executa e quais recursos o agente poderá acessar por meio dele?"

O que AppSec deveria começar a inventariar

Antes de comprar uma nova ferramenta, uma organização pode começar com visibilidade.

Algumas perguntas simples:

1. Quais coding agents estão autorizados?
2. Quais MCP Servers existem nos endpoints?
3. Quem pode instalar novos servidores, skills ou plugins?
4. Quais sistemas cada integração consegue acessar?
5. As permissões são somente leitura quando possível?
6. Tokens são pessoais, compartilhados ou específicos por workload?
7. Existe expiração e rotação?
8. O agente pode executar shell sem aprovação?
9. Instalações de dependências passam pelos mesmos repositórios e políticas do restante da empresa?
10. Existe log suficiente para reconstruir o que o agente fez?
11. Código criado ou alterado por agente passa pelos mesmos gates do código humano?
12. Há um processo simples para revogar rapidamente uma integração?

Se essas respostas dependem da memória de cada desenvolvedor, já existe uma lacuna de governança.

Uma arquitetura mínima para uso corporativo

Não existe um único desenho válido, mas uma arquitetura defensável tende a separar confiança e execução.

1. 01Agente aprovadoidentidade e configuração conhecidas
2. 02MCP e toolscatálogo, origem e permissões controladas
3. 03Autorizaçãomenor privilégio e credenciais de curta duração
4. 04Execuçãolimites e aprovação para ações críticas
5. 05Dependênciasingestão por fontes e políticas corporativas
6. 06Códigorevisão e controles AppSec
7. 07Pipelinebuild, evidência e promoção
8. 08Observabilidadelogs, detecção e resposta

O objetivo não é exigir aprovação manual para cada ação simples. É definir quais ações podem acontecer automaticamente e quais cruzam uma fronteira de risco que exige controle adicional.

Segurança agentic não deveria virar um silo

Existe o risco de criar uma nova disciplina isolada chamada “AI Security” e repetir problemas que AppSec já aprendeu a resolver.

Identidade, menor privilégio, origem confiável, validação de dependências, segregação, observabilidade e resposta continuam relevantes.

O que muda é a localização desses controles.

Parte do risco agora surge:

• No ambiente local do desenvolvedor;
• Na configuração do agente;
• Na integração com ferramentas;
• Antes do commit;
• Durante decisões automatizadas.

Por isso, o caminho mais sustentável é estender o programa de AppSec existente para cobrir a nova superfície, e não criar uma governança paralela sem integração.

O teste prático

Escolha um coding agent usado na empresa e tente responder:

Quais sistemas ele acessa, com qual identidade, por meio de quais tools, sob quais políticas e com quais evidências?

Se a resposta não puder ser obtida rapidamente, o problema não é necessariamente a IA.

É falta de visibilidade sobre uma nova fronteira da Software Supply Chain.

Fontes e referências

• Model Context Protocol — Specification 2026-07-28
• Model Context Protocol — Authorization Security Considerations
• Model Context Protocol — Security Best Practices
• NIST — Summary Analysis of Responses Regarding Security Considerations for AI Agents
• OpenSSF — Securing Agentic AI
• Snyk Research — What nearly 10,000 developer environments reveal about agentic development risk
• Postmark — Security Alert: Malicious 'postmark-mcp' npm Package Impersonating Postmark

Seu ambiente de desenvolvimento com IA já tem fronteiras de confiança definidas?

A Xmart apoia a avaliação de arquitetura, governança e controles de AppSec e Software Supply Chain em ambientes modernos de desenvolvimento.

Solicitar avaliação técnicaConhecer soluções Xmart →