Como adicionar segurança ao seu fluxo de trabalho de código de IA (sem o abrandar)

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

Protege-se ao controlar o que o agente escreve e faz, no ciclo, em vez de apenas inspecionar o diff depois do facto. O pull request costumava ser a casa da AppSec porque um humano abrandava para o ler. Um agente de IA não corre à cadência humana, por isso um controlo que só age no PR está a rever história, não a preveni-la. A correção é adicionar controlos em cada ponto onde o risco entra: quando o agente escreve, quando age, quando o código é analisado, e quando é integrado.

Pense nisto como quatro pontos de controlo ao longo do caminho que uma alteração percorre, do prompt à produção. Os mais cedo previnem; os mais tarde apanham. Quer os quatro, mas a alavancagem está concentrada no início: uma vulnerabilidade que nunca é escrita não precisa de triagem, de correção nem de revisão.

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

Passo 1: Coloque as suas regras no agente (momento do prompt)

O controlo de maior alavancagem é o que a maioria das equipas não tem: as suas regras nas mãos do agente antes de ele escrever. Um modelo não consegue seguir uma norma que nunca vê, por isso carregue os seus requisitos de segurança (parametrize queries, restrinja cada consulta a quem chama, nunca embuta um segredo) e as suas convenções de negócio (o dinheiro usa Decimal, as escritas passam por requireOwner, as queries são restringidas ao tenant) no contexto do agente para cada edição. O padrão seguro torna-se a omissão para a qual ele recorre, 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 seu endpoint". É também o controlo mais barato de correr, porque não produz nada para triar. O modelo mais aprofundado está em segurança de agentes de código de IA; o ponto prático é que este único movimento remove classes inteiras de descoberta antes de existirem.

Passo 2: Guarde as ações perigosas (momento da ação)

Os agentes de IA não só escrevem, agem: correm comandos de shell, leem ficheiros, chamam ferramentas por MCP. Por isso o segundo ponto de controlo assenta nas ações, não no código. Uma guarda interceta a chamada perigosa, um sudo rm -rf, uma leitura em bruto de uma variável de ambiente com forma de segredo, um psql ad-hoc contra um host com aspeto de produção, antes de disparar, e bloqueia ou avisa conforme a regra, com cada interceção registada.

Isto importa 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 que age sobre a intenção de um atacante, e a única coisa entre uma instrução injetada e um comando destrutivo é um controlo que vigia a própria ação. Mantenha os modos de auto-execução desligados em qualquer ambiente com dados reais, e deixe a guarda ser a rede de segurança.

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

Continue a analisar, mas mude o que faz com os resultados. Corra SAST consciente da alcançabilidade, mais análise de SCA, segredos, licenças, IaC, contentor e CI/CD, continuamente em cada push, de modo que as novas descobertas surjam à medida que o agente entrega. Depois feche o ciclo: coloque essas descobertas confirmadas e ordenadas de volta no contexto do agente para que ele remedeie as reais na mesma sessão em que já está a programar. A análise encontra; o agente corrige; você aprova. Cobrimos este ciclo em remediação de vulnerabilidades com IA.

A razão para filtrar primeiro por alcançabilidade é o volume. Um agente que gera milhares de linhas por dia gera descobertas ao mesmo ritmo, e um scanner que levanta 1200 problemas onde 12 são exploráveis treina toda a gente a ignorar os 1200. Trabalhar a partir do conjunto alcançável é o que mantém a dívida acionável, o tema de porque é que a maioria das descobertas de SAST é ruído.

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

Mantenha os controlos que já tem, são a rede de segurança. Um gate de SAST que falha o build em descobertas de alta severidade e alcançáveis, mais revisão humana com escrutínio extra sobre autenticação, queries e autorização, apanha o que os passos anteriores falharam. Adicione autofix para que o agente limpe a dívida existente em vez de a deixar crescer: aponte-o a um patamar de severidade e deixe-o abrir correções que aprova.

O erro é fazer do PR o único controlo, porque à cadência da IA ninguém lê milhares de linhas geradas de uma ponta à outra. O gate do PR é necessário e insuficiente; funciona porque os três primeiros passos já afinaram o que chega até ele.

Que aspeto tem isto de uma ponta à outra

Na prática o conjunto é uma sessão de programador, não um lançamento de programa. O programador faz o prompt como de costume; as regras já estão no agente, por isso o código sai mais seguro. A guarda assenta nas chamadas perigosas. A análise corre em segundo plano e revela o que está 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 é como proteger uma aplicação inteira em cinco minutos.

O VibeDefend é a camada que instala os três primeiros pontos de controlo com um comando. Liga o Claude Code, o Cursor, o Windsurf, o OpenAI Codex e o VS Code Copilot a quatro camadas de governação dentro do ciclo do agente, em cerca de cinco segundos, sem contentor, sem YAML e sem alteração de pipeline.

As quatro camadas mapeiam exatamente para os pontos de controlo: Business Rules extraídas do seu repositório e 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 Live Findings liga o agente aos seus scanners da CybeDefend para que as descobertas do momento da análise voltem ao agente para corrigir. Nada do seu código atravessa a rede; apenas metadados de governação estruturados o fazem, em tenants da EU ou dos US mantidos fisicamente separados. O seu 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?

Ao adicionar controlos nos quatro pontos onde o risco entra, não apenas no pull request: momento do prompt (regras carregadas no agente para que ele escreva o padrão seguro primeiro), momento da ação (uma guarda que bloqueia comandos destrutivos e leituras de segredos), momento da análise (análise consciente da alcançabilidade devolvida ao agente para remediar), e momento do PR (um gate de SAST mais 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 o mantém rápido.

Adicionar segurança abranda os programadores?

Não, quando os controlos correm 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 chamadas genuinamente perigosas; as descobertas voltam à mesma sessão; e o autofix remove trabalho em vez de o adicionar. O que abranda as equipas é o oposto, uma dívida de descobertas pós-merge que ninguém tem tempo de triar. Mover o controlo para mais cedo reduz essa carga.

Qual é o controlo mais importante a adicionar primeiro?

Regras no agente no momento do prompt. É o controlo de maior alavancagem e mais barato porque a vulnerabilidade que previne nunca tem de ser encontrada, triada, corrigida nem revista. Um modelo não consegue seguir uma norma que nunca vê, por isso carregar as suas regras de segurança e de negócio no contexto dele para cada edição remove classes inteiras de descoberta 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 de CI e a análise de dependências ficam como rede de segurança para tudo o que os controlos anteriores falham e para o código que os humanos ainda escrevem à mão. A mudança é que já não são o único controlo, porque à velocidade da IA ninguém revê milhares de linhas geradas de uma ponta à outra. Governar no momento da geração afina o que chega ao gate, por isso o gate volta a ser eficaz em vez de sobrecarregado.

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

As funcionalidades embutidas (sandboxes, modos de aprovação, exclusões de conteúdo) protegem onde o agente corre e o que pode tocar; dizem pouco sobre a segurança do código que ele escreve ou sobre as suas regras de negócio específicas. Este manual adiciona a camada em falta: as suas regras no agente, uma guarda nas suas ações, e as descobertas dos seus scanners nas suas mãos. Use ambos, os controlos nativos do agente para contenção, 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 Windsurf, ao OpenAI Codex e ao VS Code Copilot, porque partilham uma forma agêntica: leem, escrevem, executam e chamam ferramentas. Uma instalação liga todos eles ao mesmo ciclo governado, por isso o fluxo de trabalho é idêntico independentemente do agente que um dado programador prefira. As especificidades por agente estão nos nossos guias do Claude Code e do Windsurf.