Entenda os fluxos tóxicos no MCP e os riscos ocultos dos sistemas nativos de IA

A maioria das discussões sobre segurança de IA ainda se concentra em prompts, modelos e acesso direto a dados. Esses aspectos são importantes, mas, quando um agente de IA pode chamar ferramentas, invocar APIs e atuar em vários sistemas, o risco real muda de foco. Já não se trata apenas do que o modelo pode ver, mas do que o agente pode fazer quando começa a combinar ferramentas por conta própria.

É nesse contexto que o conceito de fluxo tóxico se torna importante.

Um fluxo tóxico é uma sequência de ações de um agente que leva um ambiente de instruções controladas por um invasor a dados confidenciais e, em seguida, a um ponto de exfiltração. Nenhuma das etapas precisa ser mal-intencionada por si só. Cada ferramenta pode estar fazendo exatamente aquilo para que foi projetada. O perigo está no caminho completo criado quando ferramentas, dados e instruções são combinados sob o controle de um agente de IA.

O Model Context Protocol (MCP) amplia os dois lados dessa equação. O MCP padroniza a forma como modelos e agentes se conectam a ferramentas, repositórios, serviços e fontes de dados. Para as equipes de desenvolvimento, isso é uma grande vantagem: elas passam a contar com uma maneira consistente de integrar IA aos fluxos de trabalho do dia a dia, como ler issues, atualizar tickets, consultar logs, modificar código e executar scripts. Ao mesmo tempo, o MCP oferece aos agentes um conjunto flexível de ferramentas que facilita a criação inadvertida de fluxos tóxicos.

Em uma aplicação determinística tradicional, uma determinada entrada percorre um caminho definido pelo código. Os engenheiros podem enumerar esses caminhos, testá-los e avaliar suas propriedades de segurança. Um agente baseado em MCP se comporta de outra forma. Ele pode escolher entre várias ferramentas, em ordens diferentes, com base em instruções em linguagem natural, no contexto e nas descrições das ferramentas. Ninguém escreve explicitamente todas as sequências possíveis. O modelo escolhe o caminho durante a execução.

Essa mudança cria uma nova categoria de exposição. Já não basta perguntar se um modelo tem acesso a segredos ou repositórios privados. A pergunta mais relevante passa a ser: em que condições um agente decidirá mover dados confidenciais por uma cadeia de ferramentas que, no fim, os expõe a alguém não confiável?

“Fluxo tóxico” é o termo usado para essa cadeia. Ele reforça que o risco é emergente: é uma propriedade da forma como dados e controle circulam por vários componentes, e não uma simples consequência de uma única configuração incorreta. Em ambientes MCP, entender e governar esses fluxos é essencial, pois os agentes já estão conectados a sistemas importantes: ambientes de desenvolvimento, controle de código-fonte, fluxos de resposta a incidentes e serviços próximos da produção.

A tríade letal: como uma cadeia de ferramentas leva a uma violação

Apesar da variabilidade do comportamento dos agentes, o padrão por trás dos fluxos tóxicos é surpreendentemente consistente. Ao analisar incidentes reais, três elementos costumam aparecer juntos em uma única execução de agente:

• instruções influenciadas por um invasor

• acesso a dados confidenciais

• uma forma de exfiltrar esses dados

Quando essas três condições coexistem em um fluxo, o ambiente fica exposto, mesmo que cada ferramenta envolvida tenha sido adicionada por um motivo legítimo.

Instruções não confiáveis costumam ser o ponto de partida. Em um ambiente MCP, elas não se limitam a um prompt de chat. Um invasor pode manipular o conteúdo de uma issue do GitHub, um ticket de suporte ao cliente, uma mensagem em um canal de chat monitorado ou qualquer outro objeto que o agente esteja configurado para ler. Se o objetivo do agente é classificar, resumir ou executar ações com base nesses itens, o invasor encontrou um caminho para influenciar o processo de raciocínio do agente.

Dados confidenciais geralmente ficam por trás de ferramentas criadas para aumentar a produtividade. Isso pode incluir ações como ler o conteúdo de repositórios, recuperar arquivos de configuração, consultar sistemas de acompanhamento de issues, buscar logs ou acessar registros internos. Os engenheiros querem que o agente veja as mesmas informações que usariam para corrigir um bug ou entender um problema em produção. Por isso, o conjunto de ferramentas do agente costuma incluir acesso direto a dados de alto valor.

Pontos de exfiltração são ferramentas ou canais capazes de levar dados para fora de seu perímetro seguro. Entre os exemplos comuns estão clientes HTTP que podem chamar qualquer URL, conectores que gravam dados em sistemas de terceiros, integrações que enviam e-mails ou mensagens de chat e, em alguns casos, a própria resposta do modelo, quando quem a solicita não é confiável. Essas funcionalidades costumam ser adicionadas gradualmente, à medida que as equipes conectam seus agentes a mais fluxos de trabalho.

Um cenário simples com MCP ilustra como a tríade letal se forma. Considere um servidor MCP conectado ao GitHub que dá suporte a um assistente de desenvolvimento. O assistente lê issues de um repositório, usa ferramentas MCP para buscar arquivos e detalhes de configuração relevantes e gera resumos úteis para os responsáveis pela manutenção. Para dar suporte a testes de integração, também é disponibilizada uma ferramenta HTTP capaz de enviar solicitações para qualquer endpoint.

Um invasor abre uma issue nesse repositório com instruções detalhadas. A issue afirma que só é possível diagnosticar um bug complexo coletando arquivos de ambiente e dados de configuração da base de código e, em seguida, enviando-os como um payload JSON para uma URL específica, onde um sistema de análise externo poderá examiná-los. Do ponto de vista do agente, parece uma solicitação detalhada e razoável.

Se o agente seguir essas orientações, ele lerá a issue (instruções não confiáveis), percorrerá o repositório para coletar arquivos de configuração e de ambiente (dados confidenciais) e usará a ferramenta HTTP para enviar essas informações à URL do invasor (ponto de exfiltração). Nenhuma ferramenta, por si só, está obviamente mal configurada. A violação surge da maneira como essas ferramentas são combinadas sob o controle do modelo.

Os controles tradicionais de segurança de IA têm dificuldade para lidar com esse padrão. Filtros de prompt e firewalls de LLM inspecionam prompts e respostas individuais. Eles têm pouca visibilidade sobre as chamadas intermediárias de ferramentas e a movimentação de dados que conectam esses prompts a sistemas externos. A análise de código valida como as ferramentas são implementadas, não como serão combinadas durante a execução. As revisões de acesso confirmam que cada ferramenta tem uma finalidade legítima, mas raramente avaliam se conteúdo não confiável pode conduzir uma sequência que conecte essas ferramentas em um fluxo tóxico.

O resultado é uma lacuna. As organizações podem acreditar que protegeram seus prompts, modelos e ferramentas, enquanto o risco real está nas cadeias dinâmicas de ações orquestradas pelo MCP. Enxergar essa lacuna como a “tríade letal” ajuda a direcionar a atenção para o problema real: sempre que instruções controladas por um invasor, dados confidenciais e um caminho de exfiltração puderem ser alcançados em um único fluxo, o ambiente estará em risco, por mais cuidadosa que tenha sido a introdução de cada componente.

Por que a maioria das abordagens de segurança de IA não detecta fluxos tóxicos

Quando entendemos a tríade letal, fica claro que muitas abordagens atuais de segurança de IA são otimizadas para outra categoria de problemas. Elas se concentram no que o modelo vê e diz, e não no que o agente faz em sistemas interconectados.

Controles de prompt, filtros de conteúdo e firewalls de LLM costumam ser os primeiros controles adotados pelas organizações. Esses sistemas inspecionam entradas e saídas em busca de violações de políticas ou termos confidenciais. Eles podem reduzir o uso indevido mais evidente e impedir certas categorias de injeção de prompt. No entanto, os fluxos tóxicos costumam se desenrolar em uma série de etapas aparentemente legítimas. No exemplo do GitHub, parece que o assistente está atendendo a uma solicitação detalhada de depuração. Nada na resposta final necessariamente revela que segredos foram exfiltrados por meio de chamadas intermediárias a ferramentas.

As ferramentas convencionais de segurança de aplicações também são voltadas a artefatos estáticos e caminhos determinísticos. Analisadores estáticos, análise de composição de software e análise de infraestrutura como código são adequados a ambientes nos quais o código e as configurações definem todas as ações permitidas. Eles podem validar se as ferramentas MCP foram implementadas com segurança, se as dependências estão atualizadas e se os tokens de acesso são gerenciados corretamente. O que não conseguem capturar com facilidade é a decisão de um agente de combinar essas ferramentas de forma inesperada com base em uma entrada em linguagem natural.

O registro e o monitoramento em tempo de execução acrescentam outra camada, mas também têm limitações nesse contexto. Os engenheiros podem coletar rastros de chamadas a ferramentas, respostas e erros. Também podem investigar incidentes individuais. O desafio é combinatório: o número de fluxos possíveis dispara quando mais ferramentas e sistemas são conectados pelo MCP. Depender de revisões manuais para detectar padrões perigosos se torna impraticável, principalmente porque o comportamento do agente pode mudar com pequenas alterações na entrada ou no contexto.

Até mesmo as ofertas mais recentes de segurança específicas para IA costumam se concentrar em verificações locais. Elas podem impor restrições a parâmetros de uma ferramenta específica ou limitar o acesso de determinado agente a certos segredos. Esses controles continuam centrados nos componentes. Em geral, não analisam caminhos completos que começam com conteúdo não confiável e terminam com dados saindo do perímetro de confiança.

A consequência é uma lacuna de cobertura: os investimentos em segurança de modelos, validação de prompts e segurança de ferramentas individuais não se estendem automaticamente ao espaço de interação criado pelo MCP. O ambiente pode parecer bem controlado quando cada parte é analisada separadamente e, ainda assim, permitir fluxos tóxicos quando essas partes são combinadas.

Para resolver isso, as equipes de segurança precisam fazer uma pergunta diferente: o ambiente permite algum caminho em que instruções influenciadas por um invasor possam levar dados confidenciais a um ponto de exfiltração? A Análise de Fluxos Tóxicos foi criada para oferecer uma resposta estruturada.

Conheça a Análise de Fluxos Tóxicos

A Análise de Fluxos Tóxicos (TFA) oferece uma perspectiva baseada em grafos sobre sistemas com IA. Em vez de analisar prompts ou ferramentas isoladamente, ela mapeia as conexões entre agentes, servidores MCP, ferramentas e sistemas subjacentes. Em seguida, procura caminhos que possam formar a tríade letal.

O primeiro passo é representar o ambiente. Em um contexto MCP, isso inclui servidores MCP, os manifestos de suas ferramentas, as configurações dos modelos e agentes e os sistemas externos acessados por essas ferramentas, como controle de código-fonte, plataformas de tickets, sistemas de mensagens e endpoints HTTP genéricos. Com esses dados, a TFA cria um grafo de fluxos que mostra quais componentes podem chamar quais ferramentas, o que essas ferramentas podem acessar e para onde suas saídas podem ser enviadas.

Em seguida, esse grafo é enriquecido com atributos relevantes para a segurança. Os nós e as arestas recebem anotações que indicam se partes não confiáveis podem influenciar as instruções de origem, se os dados processados são confidenciais e se a etapa atravessa um limite de confiança. Essas anotações permitem diferenciar fluxos internos rotineiros daqueles que conectam superfícies controladas por invasores a ativos de alto valor e, depois, a destinos externos.

Com o grafo anotado, a TFA pode buscar sistematicamente caminhos em que as três condições da tríade letal estão presentes. Ela identifica sequências nas quais instruções não confiáveis podem chegar a um agente, esse agente tem acesso a ferramentas que expõem dados confidenciais e o mesmo contexto inclui um ponto de exfiltração. Esses são os fluxos tóxicos que representam caminhos de ataque realistas para um adversário determinado, que usa linguagem natural e integrações existentes em vez de malware personalizado.

Detectar é apenas parte do que é necessário. Para ser útil na prática, a TFA também precisa permitir priorização e ação. Nem todos os fluxos potenciais apresentam o mesmo nível de risco. Um caminho que pode vazar segredos de produção para um endpoint externo arbitrário tem um perfil de impacto diferente de um caminho que poderia expor metadados não confidenciais a um sistema interno controlado. A Análise de Fluxos Tóxicos pode atribuir pontuações de impacto com base em fatores como classificação dos dados, facilidade de exploração, abrangência do acesso e natureza do ponto de exfiltração, ajudando as equipes a decidir onde concentrar seus esforços.

Essa perspectiva que considera as relações do grafo permite que as equipes de segurança e plataforma respondam a perguntas que, de outra forma, seriam difíceis de abordar. Quais servidores MCP expõem combinações de ferramentas capazes de criar fluxos tóxicos? Quais agentes estão conectados ao mesmo tempo a fontes de instruções não confiáveis e a destinos de exfiltração? Como a introdução de uma nova ferramenta, como um cliente HTTP genérico, altera o conjunto de fluxos possíveis?

É importante destacar que a TFA não é uma atividade pontual. À medida que os agentes evoluem, as configurações do MCP mudam e novas ferramentas são adicionadas, o grafo de fluxos precisa ser atualizado e reavaliado. Quando tratada como uma capacidade contínua, a Análise de Fluxos Tóxicos se torna a base de uma abordagem mais madura aos riscos de sistemas nativos de IA: uma abordagem que entende o comportamento do ambiente como um todo, e não apenas a configuração de cada componente.

Isso nos leva à próxima etapa. Depois que uma organização consegue visualizar e avaliar os fluxos tóxicos, precisa decidir como impedir que eles sejam executados na prática. Ter visibilidade sem controle não basta em um ambiente no qual os agentes já têm autonomia para agir.

Por que os ambientes MCP precisam de barreiras de proteção, não apenas de visibilidade

A Análise de Fluxos Tóxicos revela onde estão os riscos nativos de IA, mas, sozinha, não evita incidentes. Se um sistema consegue identificar que determinada combinação de agente, servidor MCP e ferramenta pode criar um fluxo tóxico, ainda precisa de um mecanismo para intervir quando esse fluxo estiver prestes a ser executado.

O MCP torna essa necessidade ainda mais urgente porque conecta sistemas heterogêneos por meio de um único protocolo. Com o MCP, um agente pode acessar repositórios de código-fonte, pipelines de build, sistemas de monitoramento, plataformas de colaboração e serviços internos. Cada integração é administrada por equipes e fornecedores diferentes. Em geral, não há um ponto central nesses sistemas que permita aplicar uma única política para controlar todos os fluxos que os envolvem.

O lugar mais prático para aplicar políticas é na própria camada de IA: no nível dos servidores MCP, dos agentes que eles disponibilizam e da lógica de orquestração que determina quais ferramentas estão disponíveis e como podem ser usadas. Nesse contexto, as barreiras de proteção são mecanismos concretos de aplicação de políticas, capazes de analisar sequências de ações planejadas ou em andamento, compará-las às descobertas da análise de fluxos tóxicos e às políticas e, então, permitir, modificar ou bloquear essas sequências.

Para funcionar bem, as barreiras de proteção precisam de contexto. Elas precisam de mais do que o prompt atual ou uma única chamada de ferramenta. Devem entender qual agente está em execução, quais ferramentas estão disponíveis no ambiente, como elas estão configuradas e quais dados e sistemas externos acessam. É nesse ponto que o AI-BOM e a verificação de MCP desempenham papéis fundamentais.

O AI-BOM oferece uma descrição estruturada da pilha de IA: modelos, conjuntos de dados, frameworks, servidores MCP e integrações importantes. A verificação de MCP fornece um inventário do que está realmente instalado nos endpoints de desenvolvedores e operadores: quais servidores MCP estão instalados, quais ferramentas eles disponibilizam e como estão configurados. Em conjunto, esses recursos permitem que uma camada de orquestração associe as descobertas da TFA a contextos concretos de execução.

Com essas informações, é possível aplicar barreiras de proteção em pontos precisos. Se a Análise de Fluxos Tóxicos identificar que determinado agente e configuração MCP permitiriam que issues não confiáveis do GitHub levassem segredos a um endpoint HTTP externo, uma política poderá impedir essa combinação específica sem afetar outros fluxos. Assim, evitam-se restrições amplas e indiscriminadas que comprometem a utilidade dos agentes.

Sem esse tipo de aplicação integrada, as organizações correm o risco de repetir um padrão conhecido: painéis completos e descobertas relevantes, mas pouco impacto no dia a dia. As barreiras de proteção fecham o ciclo entre análise e ação, garantindo que a conscientização sobre fluxos tóxicos se traduza em limites concretos para o que os agentes podem fazer.

Da análise ao controle: barreiras de proteção na prática e a importância de uma governança unificada

Transformar as descobertas sobre fluxos tóxicos em barreiras de proteção eficazes para MCP exige políticas, orquestração e integração com as ferramentas existentes.

As políticas são o ponto de partida. As equipes de segurança, plataforma e desenvolvimento definem em conjunto os limites que não podem ser ultrapassados. Por exemplo, podem proibir fluxos em que agentes expostos a chamados externos acessem segredos de produção e enviem dados a URLs arbitrárias, ou exigir controles adicionais para fluxos que envolvam dados regulamentados. A Análise de Fluxos Tóxicos fornece as evidências necessárias para definir e justificar essas políticas.

Em seguida, uma camada de orquestração avalia o comportamento dos agentes com base nessas políticas. Quando um agente está prestes a executar, via MCP, uma sequência de chamadas de ferramentas que completaria um fluxo tóxico, a barreira de proteção pode intervir. Ela pode bloquear a sequência, solicitar autorização adicional ou encaminhar a solicitação por um fluxo mais seguro. A aplicação da política ocorre perto do ponto de decisão do agente, onde todo o contexto do fluxo está visível.

Para expandir essa abordagem, as organizações precisam de uma camada de governança que coordene todo o ecossistema. O AI-BOM e a verificação de MCP fornecem a essa camada informações precisas e atualizadas sobre ambientes MCP gerenciados centralmente e instalados localmente. Assim, a camada de governança pode aplicar barreiras de proteção consistentes, seja em um agente executado em uma plataforma compartilhada ou na máquina de um desenvolvedor.

A correção local continua sendo essencial. O objetivo não é substituir sistemas de CI/CD, assistentes de IDE, plataformas de chamados ou ferramentas de governança de dados, mas garantir que todos atuem com base em um entendimento compartilhado dos riscos. Quando a TFA identifica um novo fluxo tóxico, a plataforma de orquestração pode abrir issues, sugerir mudanças de configuração ou atualizar regras de acesso nos sistemas que as equipes já usam. A camada de governança se torna o ponto de coordenação; as ferramentas existentes continuam sendo responsáveis por executar as mudanças.

À medida que a adoção cresce, esses recursos permitem que as organizações passem de controles experimentais para um programa coerente de segurança de IA. Elas podem começar com a visibilidade proporcionada pela Análise de Fluxos Tóxicos, adicionar barreiras de proteção direcionadas aos fluxos de maior risco e, depois, ampliar essa proteção gradualmente. Ao longo de todo o processo, o AI-BOM e a verificação de MCP garantem que as políticas continuem alinhadas ao estado real do ambiente.

O MCP está prestes a se tornar um componente central dos sistemas nativos de IA. A Análise de Fluxos Tóxicos, combinada a barreiras de proteção baseadas em inventários precisos e em uma governança unificada, oferece uma forma de aproveitar seus benefícios e manter sob controle os riscos mais graves. À medida que esses recursos evoluem, o caminho fica claro: as organizações precisam de formas práticas de colocar esse tipo de análise em ação.

Quer saber mais? Descubra como a Snyk está ampliando a proteção de sistemas nativos de IA e experimente hoje o Snyk MCP Scan.