Você já tem um orçamento para segurança de IA. E agora?

Principais conclusões

• Os orçamentos para segurança de IA precisam deixar de financiar ferramentas desconectadas e se tornar um investimento unificado em visibilidade, governança e controle em todo o ciclo de vida da IA.

• As organizações devem investir em duas frentes interligadas: proteger o desenvolvimento agentivo, no qual agentes de IA geram código, usam ferramentas e executam fluxos de trabalho, e proteger aplicativos agentivos, nos quais os agentes interagem com usuários, dados, APIs e sistemas de produção.

• Um orçamento robusto para segurança de IA deve prever recursos específicos para descoberta de IA, avaliação de riscos de agentes e modelos, aplicação de políticas, testes adversariais, proteção em tempo de execução e evidências de governança.

• Governança e conformidade devem ter uma rubrica orçamentária própria, em vez de ficarem escondidas nos gastos com ferramentas ou serem deixadas para a equipe de GRC. As equipes precisam de descoberta contínua, políticas aplicáveis, relatórios de risco e trilhas de auditoria para comprovar que os sistemas de IA são gerenciados com responsabilidade.

• Comprar ferramentas de segurança de IA pontuais e desconectadas pode aumentar os custos e a complexidade sem oferecer controle unificado. Uma abordagem de plataforma ajuda as equipes de segurança a conectar visibilidade de IA, inteligência de risco, aplicação de políticas e evidências em desenvolvimento e produção.

A maioria das organizações gasta seu orçamento de segurança de IA na camada errada. A reação instintiva é simplesmente comprar visibilidade para inventariar modelos, mapear APIs e disponibilizar um painel.

Mas só a visibilidade não impedirá o agente de programação que acabou de adicionar um servidor MCP comprometido. Não impedirá o agente em produção que está prestes a encaminhar os dados de um cliente para um destino indevido. Também não impedirá um fluxo de trabalho autônomo de encadear cinco ações individualmente “permitidas” e gerar um resultado perigoso.

Visibilidade sem aplicação de políticas não é governança. As organizações que estão adotando agentes de IA agora precisam proteger duas frentes distintas, mas interligadas:

1. Os agentes que desenvolvem software

2. Os agentes que operam dentro de aplicativos em produção

O desafio orçamentário que os líderes de segurança precisam resolver agora não é saber se conseguem detectar riscos de IA depois que eles acontecem, mas se conseguem governar os agentes durante todo o ciclo de vida, desde a criação até o comportamento em produção. Para isso, é preciso proteger os dois lados: antecipar a segurança para proteger o código gerado por IA e a cadeia de suprimentos de agentes durante o desenvolvimento de software, além de garantir visibilidade e governança sobre agentes e aplicativos em produção.

Frente 1: proteger os agentes que desenvolvem software

No desenvolvimento agentivo, os agentes de IA agora adicionam dependências, invocam servidores MCP, executam scripts, encadeiam ações em diferentes ambientes e geram código pronto para produção com pouca revisão humana. Isso cria três superfícies de risco que a AppSec tradicional não foi projetada para controlar: o que os agentes usam, o que fazem e o que geram.

1. O que os agentes usam: servidores MCP, habilidades e ferramentas externas

Agentes de programação com IA não começam do zero. Para concluir tarefas, eles incorporam continuamente servidores MCP, APIs externas, habilidades reutilizáveis, componentes de código aberto, plug-ins e ferramentas de terceiros — qualquer um deles pode ser vulnerável, malicioso ou estar configurado incorretamente.

Esses componentes são selecionados e invocados em tempo de execução, sem aprovação prévia. Isso significa que ferramentas externas não confiáveis podem ser introduzidas no fluxo de trabalho em um instante. Se uma ferramenta de segurança verifica apenas o artefato final, ela não detecta o momento em que o risco entrou no fluxo de trabalho: quando o agente selecionou e usou uma entrada não confiável.

Pesquisas da Snyk já identificaram recursos maliciosos em agentes em ecossistemas compartilhados, servidores MCP vulneráveis e falhas críticas em infraestruturas de agentes amplamente utilizadas. CVE-2025-6514, por exemplo, expôs o mcp-remote à execução remota completa de código.

2. O que os agentes fazem: execução de ferramentas, scripts e acesso ao sistema

Os agentes não apenas sugerem: eles executam ações de forma autônoma e na velocidade das máquinas. Quando recebem um objetivo, podem executar comandos, modificar arquivos, interagir com a infraestrutura, consultar sistemas, chamar APIs e encadear fluxos de trabalho em vários ambientes — muitas vezes com permissões amplas, supervisão limitada e sem uma etapa de aprovação humana.

O incidente da Replit deixou esse tipo de falha bem claro: um agente de IA ignorou instruções explícitas para “congelar” as operações, excluiu um banco de dados de produção e inventou milhares de registros falsos para esconder o que havia feito.

Esse tipo de incidente não acontece porque um scanner deixou passar uma função vulnerável. Acontece porque o comportamento dinâmico e em várias etapas do agente não foi governado no momento da ação. O desenvolvimento agentivo exige controles dentro do ciclo de execução, próximos o suficiente para avaliar o contexto, as permissões e os riscos antes que uma ação insegura seja concluída.

3. O que os agentes geram: código e dependências

Os agentes também geram código e dependências mais rápido do que as pessoas conseguem validar em uma revisão. Esse conteúdo pode incluir vulnerabilidades, dependências inseguras, segredos embutidos no código ou configurações incorretas.

No desenvolvimento agentivo, o problema é que a IA produz código continuamente, na velocidade das máquinas e muitas vezes fora dos processos de revisão adotados pelas organizações. Quando a verificação após o commit é executada, o conteúdo vulnerável talvez já esteja no repositório. Em alguns fluxos de trabalho, ele pode até já ter sido empacotado, implantado ou reutilizado por outro agente.

Proteger o conteúdo gerado significa validar o código no momento em que é criado, antes que entre no repositório ou se torne parte de um fluxo de trabalho maior conduzido por agentes. No desenvolvimento agentivo, se você não proteger o que os agentes geram desde a criação, vai correr atrás do risco depois que ele já tiver sido introduzido.

Frente 2: proteger os agentes que operam dentro de aplicativos em produção

A segunda frente é a produção. A maioria das organizações já tem agentes operando dentro de aplicativos, como agentes de suporte que atendem a solicitações de clientes, agentes de fluxo de trabalho que acessam sistemas internos, pipelines autônomos que chamam APIs e aplicativos nativos de IA que recuperam dados, tomam decisões e agem sem intervenção humana.

A questão é: você sabe o que seus agentes estão fazendo e consegue impedi-los quando agem de forma indevida? Quando os agentes entram em operação, a governança falha em três dimensões: descoberta, avaliação de riscos e conformidade.

1. Descoberta: não é possível governar agentes que você não consegue ver

As equipes de segurança precisam de uma visão atualizada de onde os agentes de IA estão operando, quais modelos usam, quais ferramentas invocam, quais dados acessam e quais fluxos de trabalho executam.

A maioria das organizações não tem essa visão completa. A IA paralela agrava o problema: funcionários e equipes criam ferramentas personalizadas de IA generativa, incorporam agentes aos fluxos de trabalho e conectam sistemas de IA a dados internos sem uma análise formal de segurança. Portanto, uma lacuna no inventário não significa apenas documentação incompleta de sistemas conhecidos; significa também agentes desconhecidos operando fora dos canais estabelecidos.

Se você não sabe quais agentes existem, não pode aplicar políticas a eles, avaliar seus riscos, comprovar a conformidade nem atribuir responsabilidades quando algo dá errado. O inventário é a base da governança, mas não é o objetivo final.

2. Avaliação de riscos: as regras precisam ser aplicadas onde os agentes agem

Muitas organizações já têm políticas de governança de IA. O problema é que a maioria delas fica em documentos, planilhas ou fluxos de revisão que os agentes nunca encontram. Essa “governança no papel” cria uma perigosa falsa sensação de segurança.

Por exemplo, uma política que determina que “agentes não podem expor dados de clientes a serviços externos” só importa se for aplicada quando o agente tentar agir. Caso contrário, a organização tem governança no papel e comportamento sem controle em produção.

Aplicativos agentivos precisam de aplicação de políticas na camada de execução, onde as regras avaliam o que o agente está tentando fazer, quais dados está acessando, quais ferramentas está invocando e se a ação ultrapassa um limite definido. Assim, se um agente manipulado tentar enviar dados de clientes para um endpoint externo, a ação poderá ser bloqueada ou modificada antes de ser concluída.

3. Conformidade: é preciso comprovar o que aconteceu, por quê e com qual autorização

Quando um agente causa um problema para a empresa, as equipes de segurança precisam de mais do que registros. Precisam de um relato confiável do que aconteceu: o que o agente fez, quais dados acessou, que ferramenta invocou, qual política se aplicava, se a ação foi permitida ou bloqueada e quem era responsável pelo fluxo de trabalho.

O caso da Air Canada mostrou que as organizações podem ser responsabilizadas pelo que um chatbot de IA diz aos clientes. O incidente de injeção de prompt da Chevrolet mostrou como é fácil manipular uma IA voltada ao público para gerar resultados com impacto nos negócios. Fluxos tóxicos mostram como os agentes podem encadear ferramentas, dados e APIs de maneiras que nenhuma ação isolada revelaria.

Governança e conformidade devem ter uma rubrica orçamentária própria para segurança de IA, em vez de ficarem escondidas nos gastos com ferramentas ou serem tratadas como uma tarefa posterior de GRC. À medida que os agentes de IA se espalham pelos fluxos de desenvolvimento e aplicativos de produção, as organizações precisam comprovar quais sistemas de IA existem, quais políticas se aplicam a eles e se essas políticas estão sendo aplicadas. Sem essa base, o custo da governança aparece mais tarde na forma de auditorias reprovadas, negociações corporativas paralisadas, investigações após incidentes ou consultorias contratadas às pressas para reconstruir uma trilha de auditoria que deveria existir desde o início.

Por que não funciona comprar duas ferramentas desconectadas

O risco de IA não fica organizado em uma única camada. Um modelo, uma estrutura de agente ou um servidor MCP pode ser introduzido no código, implantado por um pipeline, invocado por um aplicativo e, em seguida, usado por um agente para agir em produção. Se cada etapa for governada por uma ferramenta diferente, as equipes de segurança terão de juntar visões parciais do mesmo sistema.

O risco de IA não fica organizado em uma única camada. Um modelo, uma estrutura de agente ou um servidor MCP pode ser introduzido no código, implantado por um pipeline, invocado por um aplicativo e, em seguida, usado por um agente para agir em produção. Se cada etapa for governada por uma ferramenta diferente, as equipes de segurança terão de juntar visões parciais do mesmo sistema.

Ferramentas fragmentadas geram controles fragmentados. Isso resulta em:

• Políticas inconsistentes entre desenvolvimento e tempo de execução

• Inventários duplicados e divergentes

• Pontos cegos entre desenvolvimento e implantação

• Trilhas de auditoria separadas que contam apenas parte da história

• Responsabilidades indefinidas quando ocorre um incidente envolvendo agentes

Isso também gera custos fragmentados, pois cada ferramenta pontual traz sua própria licença, trabalho de integração, pipeline de dados, painel e relacionamento com fornecedor para gerenciar. Muitas vezes, as equipes duplicam esforços em recursos sobrepostos de descoberta, análise de riscos e aplicação de políticas, enquanto ainda deixam lacunas entre eles. Quando várias ferramentas são integradas, o custo e a complexidade totais podem superar o valor de uma plataforma unificada, sem oferecer controle unificado.

Em segurança de IA, a consolidação vai além de uma decisão orçamentária. É um requisito de governança. As equipes de segurança precisam de uma visão conectada de onde a IA está presente, dos riscos que ela introduz, de como se comporta e das políticas aplicadas durante todo o seu ciclo de vida. Sem essa conexão, as organizações podem gastar mais e ainda não ter a visibilidade, a responsabilização e o controle necessários para ampliar a adoção de IA com segurança.

A Snyk protege os dois lados da segurança agentiva em uma única plataforma

A AI Security Platform da Snyk protege os dois lados do ciclo de vida dos agentes em uma única plataforma. No desenvolvimento agentivo, a Snyk ajuda a governar o que os agentes usam, fazem e geram — de servidores MCP e habilidades à execução e ao código gerado por IA. Para aplicativos agentivos em produção, a Snyk oferece um sistema de registro de riscos de IA que abrange agentes, modelos, ferramentas, dados e fluxos de trabalho por meio do Evo AI-SPM, transformando as intenções de governança em políticas aplicáveis.

O resultado é uma única camada de controle para a segurança de agentes: descoberta compartilhada, políticas compartilhadas, aplicação em tempo real e capacidade de auditoria em desenvolvimento e produção.

Juntos, esses elementos criam um modelo unificado de segurança para agentes:

• Um único sistema de registro para riscos de IA e agentes

• Um único modelo de políticas para desenvolvimento e produção

• Uma única camada de aplicação de políticas para comportamentos inseguros de agentes

• Uma única trilha de auditoria para governança e responsabilização

A pergunta a responder antes de fechar o orçamento

Se você tem um orçamento para segurança de IA e uma equipe de liderança que espera resultados, a pergunta decisiva é simples: Você consegue aplicar uma política de segurança a um agente — em desenvolvimento e em produção — antes que uma ação insegura seja concluída?

Se a resposta for não, você não tem segurança para agentes e não está adequadamente preparado para o próximo agente que apagar um banco de dados de produção, alucinar uma política que responsabilize sua empresa, vazar dados confidenciais ou combinar ferramentas aprovadas em um fluxo de trabalho inseguro. As organizações que tiverem sucesso com IA não serão as que desacelerarem sua adoção. Serão as que incorporarem controle contínuo à forma como os agentes desenvolvem software e operam em produção.

O orçamento foi aprovado, e a ameaça é real. O próximo passo é garantir que seu programa de segurança de IA possa agir antes que uma ação insegura se transforme em um incidente de negócios. Quer um guia prático para uma governança contínua e aplicável? Baixe hoje o Guia Executivo para Operacionalizar e Aplicar a Governança de IA.