Como pôr segurança no teu fluxo de trabalho de código com IA (sem o abrandar)

Como é que se protege um fluxo de trabalho de código de IA?

Protege-se controlando o que o agente escreve e faz, dentro do ciclo, em vez de apenas inspecionar o diff quando já está feito. O pull request era a casa da AppSec porque um humano abrandava para o ler. Um agente de IA não trabalha ao ritmo humano, por isso um controlo que só atua no PR está a rever o passado, não a evitá-lo. A solução é pôr controlos em cada ponto por onde o risco entra: quando o agente escreve, quando age, quando o código é analisado e quando é integrado.

Vê-os como quatro pontos de controlo ao longo do caminho que uma alteração percorre, do prompt à produção. Os primeiros previnem; os últimos apanham. Precisas dos quatro, mas o grosso do efeito está no início: uma vulnerabilidade que nunca chega a ser escrita não precisa de triagem, de correção nem de revisão.

Momento do prompt: regras no agenteMomento da ação: guarda nas chamadas perigosasMomento da análise: descobertas de volta ao agenteMomento do PR: gate de SAST + autofix

Passo 1: Põe as tuas regras no agente (momento do prompt)

O controlo com mais impacto é justamente o que falta à maioria das equipas: as tuas regras nas mãos do agente antes de ele escrever. Um modelo não consegue seguir uma norma que nunca vê, por isso carrega no contexto do agente, em cada edição, os teus requisitos de segurança (parametriza as queries, restringe cada consulta a quem a faz, nunca embutas um segredo) e as tuas convenções de negócio (o dinheiro usa Decimal, as escritas passam por requireOwner, as queries ficam restritas ao tenant). O padrão seguro passa a ser aquilo que ele escreve por defeito, e não algo que um scanner assinala mais tarde.

É isto que transforma «o agente escreve o endpoint médio da internet» em «o agente escreve o teu endpoint». É também o controlo mais barato, porque não produz nada para triar. O modelo completo está em segurança de agentes de código de IA; na prática, este único gesto elimina classes inteiras de descobertas antes de elas existirem.

Passo 2: Põe uma guarda nas ações perigosas (momento da ação)

Os agentes de IA não se limitam a escrever, também agem: correm comandos de shell, leem ficheiros, chamam ferramentas por MCP. Por isso o segundo ponto de controlo incide sobre as ações, não sobre o código. Uma guarda interceta a chamada perigosa (um sudo rm -rf, a leitura em bruto de uma variável de ambiente com cara de segredo, um psql ad hoc contra um host com ar de produção) antes de ela disparar, e bloqueia ou avisa conforme a regra, registando cada interceção.

Isto pesa ainda mais quando o agente pode ser manipulado. A injeção de prompt (instruções escondidas num ficheiro, numa página web ou numa resposta de ferramenta MCP) transforma um agente prestável num agente que obedece à intenção de um atacante, e entre uma instrução injetada e um comando destrutivo só existe um controlo que vigie a própria ação. Mantém os modos de execução automática desligados em qualquer ambiente com dados reais e deixa a guarda servir de rede de segurança.

Passo 3: Analisa continuamente e devolve as descobertas ao agente (momento da análise)

Continua a analisar, mas muda o que fazes com os resultados. Corre SAST com filtro de alcançabilidade, mais análise de SCA, segredos, licenças, IaC, contentores e CI/CD, de forma contínua em cada push, para que as novas descobertas apareçam ao ritmo a que o agente entrega. Depois fecha o ciclo: põe essas descobertas, confirmadas e ordenadas, de volta no contexto do agente, para que ele corrija as reais na mesma sessão em que já está a programar. A análise encontra, o agente corrige, tu aprovas. Explicamos este ciclo em remediação de vulnerabilidades com IA.

Filtra-se primeiro pela alcançabilidade por causa do volume. Um agente que gera milhares de linhas por dia gera descobertas ao mesmo ritmo, e um scanner que levanta 1200 problemas dos quais 12 são exploráveis ensina toda a gente a ignorar os 1200. Partir do conjunto alcançável é o que mantém a dívida tratável, o tema de porque é que a maioria das descobertas de SAST é ruído.

Passo 4: Controla o pull request e limpa a dívida acumulada (momento do PR)

Mantém os controlos que já tens: são a rede de segurança. Um gate de SAST que faz falhar o build perante descobertas alcançáveis de severidade alta, mais uma revisão humana atenta à autenticação, às queries e à autorização, apanha o que escapou aos passos anteriores. Acrescenta o autofix para que o agente limpe a dívida existente em vez de a deixar crescer: aponta-o a um nível de severidade e deixa-o abrir correções que tu aprovas.

O erro é fazer do PR o único controlo, porque ao ritmo da IA ninguém lê de ponta a ponta milhares de linhas geradas. O gate do PR é necessário, mas não chega; funciona porque os três primeiros passos já filtraram o que lá chega.

Como fica tudo isto de ponta a ponta

Na prática, o conjunto é uma sessão de programador, não um programa de implementação. O programador escreve o prompt como de costume; as regras já estão no agente, por isso o código sai mais seguro. A guarda vigia as chamadas perigosas. A análise corre em segundo plano e mostra o que está em aberto. O programador pede ao agente que corrija os críticos alcançáveis e aprova os diffs, e o gate do PR confirma que nada escapou. O passo a passo detalhado e cronometrado está em como proteger uma aplicação inteira em cinco minutos.

O VibeDefend é a camada que instala os três primeiros pontos de controlo com um único comando. Liga o Claude Code, o Cursor, o Devin Desktop, o OpenAI Codex e o VS Code Copilot a quatro camadas de governação dentro do ciclo do agente, sem contentor, sem YAML e sem mexer no pipeline.

As quatro camadas correspondem exatamente aos pontos de controlo: as Business Rules extraídas do teu repositório e as Security Rules de OWASP, SOC 2, RGPD e ISO 27001 são o controlo no momento do prompt; o Action Guard é o controlo no momento da ação; e o Live Findings liga o agente aos teus scanners da CybeDefend, para que as descobertas do momento da análise voltem ao agente para correção. O Action Guard decide no teu portátil; para servir as regras, o VibeDefend envia um excerto curto do código que está a ser escrito, e a análise feita antes do commit envia os ficheiros alterados, ambos para a região da UE ou dos EUA que escolheres na instalação (as duas são fisicamente separadas), e o teu código nunca é usado para treinar um modelo. O teu gate de SAST no CI e a revisão ficam onde estão, como rede de segurança.

Perguntas frequentes

Como é que se protege um fluxo de trabalho de código de IA?

Pondo controlos nos quatro pontos por onde o risco entra, e não só no pull request: momento do prompt (regras carregadas no agente para que ele escreva logo o padrão seguro), momento da ação (uma guarda que bloqueia comandos destrutivos e leituras de segredos), momento da análise (análise filtrada pela alcançabilidade e devolvida ao agente para correção) e momento do PR (um gate de SAST com revisão humana e autofix). Os dois primeiros previnem vulnerabilidades; os dois últimos apanham o que escapa. Concentrar os controlos no início é o que mantém o fluxo rápido.

Adicionar segurança abranda os programadores?

Não, se os controlos correrem dentro do ciclo em que os programadores já estão. As regras no agente mudam o que ele escreve sem nenhum passo extra; o action guard só interrompe as chamadas realmente perigosas; as descobertas voltam à mesma sessão; e o autofix tira trabalho em vez de o acrescentar. O que abranda as equipas é o contrário: uma pilha de descobertas pós-merge que ninguém tem tempo de triar. Antecipar o controlo reduz essa carga.

Qual é o controlo mais importante a adicionar primeiro?

As regras no agente, no momento do prompt. É o controlo com mais impacto e o mais barato, porque a vulnerabilidade que evita nunca tem de ser encontrada, triada, corrigida nem revista. Um modelo não consegue seguir uma norma que nunca vê, por isso carregar as tuas regras de segurança e de negócio no contexto dele, em cada edição, elimina classes inteiras de descobertas antes de existirem. Tudo o resto é uma rede de segurança por trás dele.

Continuo a precisar de SAST e de análise no CI se o agente for governado?

Sim. O SAST no CI e a análise de dependências continuam a ser a rede de segurança para tudo o que escapa aos controlos anteriores e para o código que as pessoas ainda escrevem à mão. A diferença é que deixam de ser o único controlo, porque à velocidade da IA ninguém revê de ponta a ponta milhares de linhas geradas. Governar no momento da geração filtra o que chega ao gate, e o gate volta a ser eficaz em vez de ficar afogado.

Em que é que isto difere de usar simplesmente as funcionalidades de segurança nativas do meu agente de IA?

As funcionalidades nativas (sandboxes, modos de aprovação, exclusões de conteúdo) protegem o sítio onde o agente corre e aquilo em que pode tocar; dizem pouco sobre a segurança do código que ele escreve ou sobre as tuas regras de negócio. Este manual acrescenta a camada que falta: as tuas regras no agente, uma guarda nas ações dele e as descobertas dos teus scanners nas mãos dele. Usa as duas coisas: os controlos nativos do agente para o confinar e uma camada agent-time para o próprio código.

Com que agentes funciona isto?

A mesma abordagem aplica-se ao Claude Code, ao Cursor, ao Devin Desktop, ao OpenAI Codex e ao VS Code Copilot, porque todos funcionam como agentes: leem, escrevem, executam e chamam ferramentas. Uma única instalação liga-os todos ao mesmo ciclo governado, por isso o fluxo de trabalho é idêntico seja qual for o agente que cada programador prefira. Os detalhes de cada agente estão nos nossos guias do Claude Code e do Devin Desktop.