Por que agentes de programação com IA continuam criando falhas de controle de acesso

Agentes de programação com IA geram uma lógica de autorização que compila, passa pela revisão e aplica a política errada. O controle de acesso quebrado ocupa o primeiro lugar no OWASP Top 10:2025, em que 100% das aplicações testadas apresentaram alguma forma dessa falha, em um total de 1.839.701 ocorrências registradas, o maior número entre todas as categorias da lista.

Uma parte dessa categoria também é justamente aquela que a análise baseada em padrões nunca foi projetada para detectar. Quando um agente deixa de verificar a propriedade de um recurso, a regra violada pertence à aplicação, não a um banco de assinaturas. Portanto, não há um padrão malicioso conhecido para identificar.

O que é controle de acesso quebrado?

Controle de acesso quebrado é a falha em garantir o que uma pessoa autenticada pode fazer ou ver. A pessoa comprova sua identidade e, em seguida, a aplicação entrega dados ou ações que pertencem a outra pessoa. Dois casos conhecidos respondem pela maior parte do que as equipes encontram.

1. BOLA: autorização quebrada no nível do objeto

BOLA é a falha em verificar se quem fez a solicitação tem direito ao objeto específico solicitado. Ela ocupa o primeiro lugar no OWASP API Security Top 10, ficando no topo das duas listas da OWASP relevantes para aplicações modernas.

2. IDOR: referência direta insegura a objeto

IDOR é a mesma falha vista pelo lado de quem ataca. A aplicação expõe um identificador interno, como o ID de um registro, e substituí-lo por outro valor retorna dados que pertencem a outra conta. Em geral, um único bug é tanto BOLA quanto IDOR.

A OWASP colocou essa categoria no topo da lista em 2021, e ela permaneceu nessa posição até a edição de 2025. São falhas simples. Elas continuam no topo porque são fáceis de introduzir, difíceis de detectar automaticamente e representam uma vantagem imediata quando são descobertas.

Por que agentes de programação com IA erram tanto na autorização?

O desenvolvimento de software se tornou agentivo, mas a segurança não acompanhou essa mudança. A segurança de aplicações foi construída em torno de análises que identificam padrões maliciosos conhecidos e repassam os resultados a pessoas que conhecem as regras do produto. Quando um agente escreve o endpoint, ninguém no processo segue essas regras por padrão, e a falha resultante não corresponde a nenhum padrão conhecido. Fechar essa lacuna exige mais do que outra regra.

Isso acontece porque o requisito de autorização nunca foi especificado, e o agente não está errando em relação à tarefa que recebeu. Imagine uma pessoa desenvolvedora pedindo a um agente de programação para criar um endpoint que retorna uma fatura pelo ID. O agente cria uma rota que verifica se quem fez a solicitação está autenticado, busca a fatura pelo identificador na URL, retorna um 404 quando não há correspondência e envia o registro ao cliente.

Cada uma dessas decisões está correta para a tarefa descrita. O endpoint autentica, lida com o caso em que o registro não existe e é fácil de entender durante a revisão. Também permite que qualquer pessoa autenticada leia qualquer fatura do sistema, bastando alterar um valor na URL.

A correção é acrescentar uma condição à busca: encontrar a fatura pelo identificador e pela organização à qual quem fez a solicitação pertence. Nada mais no endpoint precisa mudar.

Por que não dá para descobrir a correção apenas pelo código

Para saber que a segunda versão está correta, é preciso conhecer três fatos que não aparecem em nenhum lugar do código gerado:

• As faturas pertencem a organizações.

• O acesso de uma pessoa é limitado às organizações das quais ela faz parte.

• Neste produto, nunca é legítimo ler dados entre organizações.

Em outro produto, o terceiro fato poderia não ser verdadeiro, já que algumas plataformas permitem que auditores, revendedores ou contas principais leiam dados entre tenants por projeto. A regra é uma característica do produto, não da linguagem ou do framework. Ela está no modelo de dados, em uma decisão tomada há dois anos e na memória das pessoas engenheiras que a tomaram.

O que a pessoa revisora deve verificar

Em geral, uma pessoa desenvolvedora da equipe percebe o problema por um motivo: conhece o produto. Um agente que trabalha com base no prompt e no arquivo ao redor não tem acesso ao que torna essa verificação necessária.

Vale levar dois detalhes para a revisão. O primeiro é o código de resposta. Incluir a condição de propriedade na busca faz com que uma solicitação da fatura de outra organização retorne o mesmo 404 que uma solicitação de uma fatura inexistente. Esse é o comportamento desejado, pois um 403 confirmaria que o registro existe e permitiria que alguém que ataca enumerasse identificadores válidos. O segundo detalhe é o que a resposta retorna. Enviar o registro armazenado sem modificações inclui todos os seus campos. Por isso, o mesmo manipulador costuma apresentar um problema de exposição de dados além da falha de autorização.

Ferramentas SAST conseguem detectar falhas de controle de acesso?

Para classes de vulnerabilidade que têm um padrão, a detecção está praticamente resolvida. A autorização é uma exceção, exatamente onde o código gerado por IA é mais vulnerável. A análise estática rastreia estruturas que podem ser descritas, mas a autorização no nível do objeto não segue uma estrutura única.

Use uma injeção como contraste: uma vulnerabilidade de injeção tem uma estrutura que pode ser descrita: uma entrada não confiável chega a um ponto perigoso sem passar por sanitização. Essa estrutura pode ser transformada em uma regra. Então, um mecanismo acompanha os dados da origem ao destino e identifica todos os caminhos correspondentes.

O que a análise estática consegue cobrir no controle de acesso quebrado

O controle de acesso quebrado é a maior categoria do OWASP Top 10, mas nem todas as suas falhas resistem à análise automatizada. A01:2025 abrange 40 CWEs, e várias têm exatamente a estrutura rastreável que a análise estática consegue tratar bem, incluindo travessia de diretórios, redirecionamento aberto e falsificação de solicitação do lado do servidor. Mecanismos semânticos modernos vão além da correspondência de assinaturas ao modelar o fluxo de dados e a intenção do código. Eles também podem sinalizar a ausência estrutural de um decorador ou middleware de autorização em uma rota, quando a base de código segue uma convenção consistente.

Onde está o limite da cobertura

A parte que resiste à análise é mais específica: a autorização no nível do objeto, classificada como CWE-639 (contorno da autorização por meio de uma chave controlada pela pessoa usuária), CWE-862 (autorização ausente) e CWE-863 (autorização incorreta). Nesse caso, nenhuma chamada perigosa é feita, nenhum valor não confiável chega a um lugar indevido e todas as linhas seguem boas práticas. O defeito é a ausência de uma comparação exigida apenas pelas regras da própria aplicação.

Para sinalizar essa falha, um mecanismo precisaria saber quais campos representam a propriedade neste esquema, quais pessoas podem acessar o recurso e onde fica o limite entre os tenants. A qualidade da regra não tem relação com isso. São informações que não existem no arquivo analisado.

Mecanismos determinísticos e raciocínio devem trabalhar juntos, não competir. Para as classes que cobrem, os mecanismos retornam o mesmo resultado todas as vezes. Isso permite que uma equipe condicione a aprovação do pipeline a eles. A autorização no nível do objeto está além do que uma regra consegue descrever, então é preciso outro instrumento para lidar com ela.

Como encontrar falhas que não seguem nenhum padrão?

É possível encontrar falhas sem um padrão analisando um modelo da aplicação, em vez do arquivo que está diante de você.

Para encontrar o bug da fatura, são necessários quatro fatos: o que chama esse endpoint, a que pertence o objeto buscado, quais pessoas têm direito a ele e onde fica o limite de confiança entre os tenants. É possível recuperar esses fatos da base de código, do esquema e do que está em execução na produção, mas é preciso reuni-los de uma forma que a análise consiga interpretar. A Snyk chama esse modelo consolidado de grafo de contexto da aplicação: arquitetura, fluxos de dados, classificações de dados, limites de confiança e realidade da produção, criado uma vez e atualizado conforme o código muda. Com ele, a ausência da verificação de propriedade fica visível, pois a análise pode comparar o que o endpoint aplica com o que as próprias regras da aplicação exigem.

Três condições tornam o resultado confiável.

1. O raciocínio precisa se basear nesse modelo. Sem ele, o raciocínio de ponta gera descobertas plausíveis sobre uma base de código que imaginou em parte e consome tokens analisando às cegas.

2. As descobertas precisam ser confirmadas por algo que não as produziu. Não dá para confiar que um agente que encontra uma vulnerabilidade valide a própria correção. Um sistema que avalia a própria saída perpetua tudo o que sua análise deixou passar.

3. A correção precisa ser comprovada, não apenas proposta. A correção de uma linha precisa ser validada de acordo com as regras da aplicação, e é necessário demonstrar que continua funcionando à medida que o código muda. Uma descoberta que nunca resulta em uma correção incorporada deixa o endpoint tão exposto quanto antes.

Analisar a aplicação consolidada, com mecanismos determinísticos atuando em paralelo, é a direção que a Snyk está seguindo com o Evo Agentic AppSec, apresentado pela primeira vez em agosto. Os testes em tempo de execução confirmam o que alguém que ataca consegue alcançar, e é aí que o Evo Continuous Offensive Security entra em ação hoje.

O que sua equipe deve fazer agora?

Cinco etapas para começar, sem precisar de novas ferramentas.

1. Faça um inventário dos endpoints que aceitam um identificador de objeto na solicitação. Toda rota que recebe um ID, nome de arquivo ou chave pela URL ou pelo corpo da solicitação é uma candidata. Em geral, essa lista é menor do que as equipes esperam e maior do que gostariam.

2. Documente as regras de propriedade. Para cada tipo de recurso, registre a quem ele pertence e quem pode lê-lo ou modificá-lo. As falhas de autorização passam pela revisão porque essa informação nunca foi documentada em um lugar que uma pessoa revisora ou analista possa verificar.

3. Inclua a autorização como um item explícito na revisão de pull requests escritos por agentes. Não uma instrução genérica para revisar com atenção, mas uma pergunta específica: este endpoint verifica se quem fez a solicitação tem direito ao objeto e qual campo é usado para verificar isso?

4. Adicione um teste entre tenants para cada tipo de recurso. A orientação de prevenção da OWASP é direta: pessoas desenvolvedoras e equipes de QA devem incluir testes funcionais de controle de acesso nos testes unitários e de integração. Um teste por recurso, que verifica se uma sessão válida de um tenant recebe um 404 ao solicitar um objeto de outro tenant, transforma a regra documentada na segunda etapa em uma regra que continua sendo aplicada.

5. Faça análises profundas de toda a base de código regularmente. O ponto de controle agora se divide em três: em tempo real, no ciclo interno do agente; análises determinísticas rápidas a cada mudança no CI; e análise contextual profunda de toda a base de código. As falhas de autorização no nível do objeto aparecem na terceira etapa.

Quais dos seus endpoints falhariam hoje nesse teste entre tenants? Comece pelo inventário da primeira etapa. Para saber como a Snyk está avançando na segurança de aplicações agentivas, leia Uma primeira olhada no Evo Agentic AppSec.