Seu novo desenvolvedor é um agente de IA. Seu modelo de segurança ainda é o mesmo?

O uso de desenvolvimento de software assistido por IA já é um fato. Por um tempo, o uso de agentes e “co-pilotos” estava localizado em tarefas pontuais ou acessórias; mas a evolução dos principais modelos (como ChatGPT, Claude, Gemini e outras) e sua integração com as ferramentas de desenvolvimento aceleraram decisivamente o movimento de geração automática de código. Naturalmente, a responsabilidade pelo software entregue continua sendo humana e organizacional: delegar uma tarefa a um agente não significa delegar “accountability”.

Em algumas décadas trabalhando com desenvolvimento e arquitetura de sistemas de missão crítica, particularmente no mercado financeiro, acompanhei várias mudanças que pareciam redefinir a forma de construir software. Passamos de arquiteturas centralizadas para client/server, depois para web, aplicações móveis, cloud e plataformas distribuídas (containers e clusters). Cada transição trouxe enormes ganhos de capacidade e produtividade, e cada uma criou novas camadas de complexidade, novas superfícies de ataque, novas “fronteiras de confiança” e novas exigências para arquitetura e segurança.

Agora a IA introduz uma mudança diferente: não apenas onde e como construímos software, mas quem, ou o que, participa ativamente de sua construção.

Por que isso é um movimento racional

Vamos começar pelo contexto e pela motivação: as empresas de software querem utilizar a IA para aumentar a produtividade e diminuir o tempo de entrega dos projetos aos clientes. É um movimento perfeitamente racional e justificado. Primeiro a IA sugeria código; depois passou a receber tarefas completas; e agora agentes conseguem planejar alterações, consultar repositórios, modificar múltiplos arquivos, executar testes e interagir com ferramentas externas. O processo assistido por IA está delegando cada vez mais atividades do processo de desenvolvimento para os agentes.

A assimetria entre gerar e verificar

Uma das consequências é o aumento da produção de software: à primeira vista, OK. Outra consequência é que, à medida que agentes passam a produzir alterações em velocidade muito superior à revisão manual, surge uma assimetria: a capacidade de geração cresce mais rapidamente que a capacidade humana de validação. A questão não é assumir que todo código produzido por IA seja mais inseguro que código humano: o problema é produzir software em maior escala e velocidade sem aumentar proporcionalmente nossa capacidade de verificação.

A IA pode aumentar enormemente a produtividade do desenvolvimento. Sem governança compatível, pode aumentar também a velocidade com que erros e riscos são introduzidos.

Portanto, nesse cenário em que a velocidade de produção aumentou, como podemos implantar controles e salvaguardas para exercer uma efetiva governança do software?

Atualizar os controles sem abandonar os princípios

A resposta é: atualizar e aperfeiçoar os controles do processo de desenvolvimento para lidar com os desafios específicos trazidos pelo uso da IA. As tecnologias mudam mais rapidamente do que os princípios da boa engenharia.

Por exemplo: em ambientes tradicionais, o acesso baseado em “least privilege” era aplicado sobretudo a usuários e aplicações. Na nuvem, precisamos aplicá-lo também a workloads, service accounts, roles, funções do tipo serverless e pipelines. O princípio permaneceu, o universo de identidades ao qual ele se aplica aumentou.

Assim como fizemos esse exemplo com o princípio de “least privilege”, podemos pensar em diversos princípios e práticas de mercado: defense in depth, separation of duties, policy as code, fail securely, traceability, etc. Todos eles devem ser considerados e refinados se quisermos ter uma abordagem de adoção responsável do desenvolvimento assistido por IA.

Voltando ao título do post: se um agente de IA participa da construção de um software, como garantir que esse processo de desenvolvimento é seguro (o que chamamos de “Secure SDLC”) e que o código gerado pelo agente também possa ser considerado seguro?

As novas perguntas do Secure SDLC

Precisamos agora ampliar as perguntas “tradicionais” do Secure SDLC: quais as informações que os agentes podem ler? Em qual contexto ele pode confiar que essas informações estão corretas? Quais ferramentas ele pode utilizar? Quais credenciais ele possui? Quais comandos ele pode executar sem autorização? Quem autoriza as ações que os agentes não podem realizar sozinhos? Qual o limite da autonomia concedida aos agentes? Qual a trilha de auditoria das ações realizadas? Como podemos reconstruir ou reproduzir a sequência de decisões e ações que levou ao resultado?

Com agentes, torna-se ainda mais evidente que segurança não é apenas uma propriedade do software produzido, mas também do processo e do ambiente em que humanos e agentes o produzem.

Secure Agentic SDLC: três pilares

Podemos chamar essa evolução de um “Secure Agentic SDLC”: a adaptação dos princípios e controles do Secure SDLC para um processo no qual agentes passam a participar ativamente da engenharia de software. Esse ciclo de vida do software deve levar em conta 3 pilares:

1. Governar o que o agente pode conhecer e fazer

Definir quais informações, repositórios, documentos, credenciais, ferramentas, APIs e servidores MCP o agente pode acessar. Aplicar identidade própria, least privilege, isolamento de ambientes e limites claros de autonomia. O objetivo é garantir que o agente tenha contexto suficiente para executar a tarefa, mas não mais acesso ou capacidade do que realmente necessita.

2. Verificar, de forma independente, o que o agente produz

Nenhum resultado deve ser considerado seguro apenas porque foi produzido por um modelo avançado ou porque passou nos testes funcionais. Código, configurações e artefatos gerados devem ser submetidos a mecanismos independentes de validação, tais como testes automatizados, SAST, SCA, secret scanning, IaC scanning e policy-as-code. O princípio é simples: quem produz não deve ser o único responsável por verificar.

3. Manter os controles e evidências sobre o que o agente executa

As ações realizadas pelo agente devem ser observáveis, rastreáveis e compatíveis com o nível de risco envolvido. Operações críticas podem exigir simulação, controles adicionais, segregação de funções ou aprovação humana explícita. Deve existir uma trilha de auditoria capaz de reconstruir a origem da solicitação, as ferramentas utilizadas, as decisões relevantes e as alterações efetivamente realizadas.

O que sua empresa pode fazer hoje

Uma ação prática que toda empresa de software pode executar hoje é revisar seu processo de desenvolvimento para identificar se os pontos citados acima estão cobertos e quais lacunas existem no processo atual. Antes de planejar uma evolução com base em ferramentas e controles vendidos dentro do “hype” de IA, é fundamental avaliar o que existe hoje e quais as carências identificadas.

Queremos explorar todo o potencial da IA, e devemos fazê-lo. Mas uma adoção responsável exige adaptar nossos controles sem abandonar os princípios que aprendemos a preservar ao longo de décadas de engenharia de sistemas críticos.

As grandes mudanças tecnológicas alteram os mecanismos da segurança, não seus princípios fundamentais. O novo desenvolvedor pode ser um agente de IA. A responsabilidade pelo software continua sendo nossa.