Segurança de agentes de código de IA: o modelo agent-time

O que é a segurança de agentes de código de IA?

A segurança de agentes de código de IA é a disciplina de restringir o que um agente de código autónomo produz e executa, ao longo da geração, da execução de comandos e das chamadas de ferramentas, em vez de proteger apenas a caixa onde corre. Abrange o código que o agente escreve, as dependências que puxa, os segredos que consegue ler e as ações que pode tomar em seu nome.

A expressão é muitas vezes lida de forma demasiado estreita. A maior parte da orientação publicada trata-a como um problema de infraestrutura: pôr o agente num ambiente isolado (sandbox), delimitar o seu papel de IAM, limitar a sua saída de rede, controlar as suas permissões. Esses controlos são necessários e não estamos a argumentar contra eles. Mas respondem a uma pergunta diferente. O ambiente isolado (sandbox) decide o que o agente pode tocar. Nada diz sobre se o SQL que o agente acabou de escrever concatena input do utilizador numa query string, ou se a verificação de autorização que ele saltou vai vazar os dados de outro tenant. O tempo de execução está contido; o artefacto não. Proteger um agente de código de IA tem de incluir proteger o que ele escreve, no momento em que o escreve.

Porque é que um agente de código de IA é uma nova superfície de ataque?

Um agente de código de IA é uma nova superfície de ataque porque toma ações em vez de as sugerir. Um assistente de IDE tradicional propõe uma completação que um humano escolhe colar. Um agente lê ficheiros que não nomeou, corre comandos que não escreveu, edita código por toda a árvore e chama ferramentas que ligou há semanas. O raio de impacto já não é um bloco de código.

Duas mudanças agravam isto. A primeira é a autonomia: o agente pode ser orientado. Como um modelo de linguagem não consegue distinguir de forma fiável uma instrução de confiança de uma maliciosa enterrada em dados, um atacante pode esconder instruções num ficheiro, numa página web, numa issue ou na resposta de uma ferramenta, e o agente segue-as. Isto é injeção de prompt indireta, e é o risco número um da OWASP para aplicações LLM há três anos consecutivos. Um assistente orientado responde mal; um agente orientado age.

A segunda mudança é a velocidade, e é a que a maioria das equipas subestima. O pull request funcionava como porta de segurança porque assentava na cadência humana. O agente não corre à cadência humana. Quando uma única sessão entrega mais código numa tarde do que um revisor lê numa semana, qualquer controlo que viva apenas no PR está agora a rever o histórico, não a preveni-lo.

Porque é que a análise pós-PR falha para os agentes de IA?

A análise pós-PR falha para os agentes de IA porque foi concebida para a cadência humana e o agente quebrou essa cadência. O SAST, o SCA e o revisor humano atuam todos sobre o mesmo artefacto, o diff, e todos assumem que uma pessoa abranda para o ler antes do merge. Quando o agente ultrapassa o revisor, essa premissa deixa de se sustentar.

A falha não é que os scanners parem de encontrar bugs. Continuam a encontrá-los. A falha é de tempo e de volume. Quando um scanner assinala uma injeção no diff já feito merge, o agente já escreveu a linha, avançou, construiu três funcionalidades por cima dela, e um programador tem uma fila de descobertas para triar que cresce mais depressa do que alguém consegue limpar. As equipas respondem de duas formas previsíveis, ambas más: umas fazem merge da saída do agente com uma vista de olhos, outras juntam-na num único PR gigante que nenhum humano lê de ponta a ponta. De qualquer forma, o diff deixou de ser uma porta. É um registo do que já aconteceu.

Há também um desencontro mais profundo. As coisas mais danosas que um agente de IA erra não são os padrões em que os scanners são bons. São falhas de lógica de negócio: uma verificação de propriedade em falta, um desconto que acumula quando não devia, uma transição de estado que nunca deveria ter sido alcançável. Um scanner que não conhece o seu domínio não as consegue ver, e um revisor afogado na saída do agente também não as apanha. O controlo tem de conhecer as suas regras, e tem de atuar antes de a linha ser escrita.

O que é a segurança agent-time?

A segurança agent-time é a prática de impor os seus controlos dentro do ciclo do agente de código de IA, antes de a linha ofensiva ser escrita, em vez de depois de o código aterrar num pull request. O ponto de controlo passa do diff para o prompt. O agente lê as regras relevantes como parte de escrever o código, de modo que o requisito se torna parte da saída em vez de uma caixa a marcar no momento da auditoria.

É a resposta natural ao problema da cadência. Se o agente entrega mais depressa do que consegue rever, não ganha revendo com mais afinco. Ganha pondo a regra nas mãos do agente antes de ele agir. Em concreto, a segurança agent-time engata a sessão e as chamadas de ferramentas do agente: antes de uma edição, injeta as convenções e os requisitos de segurança que se aplicam aos ficheiros a tocar; antes de um comando destrutivo disparar, interceta. Nada espera pelo merge.

“

O pull request era um ponto de controlo porque um humano o lia. O prompt é o ponto de controlo agora porque o agente o ouve. A segurança agent-time é a camada que coloca o ouvido do agente do seu lado.

Isto não substitui os seus scanners. O SAST e o SCA continuam a pertencer ao CI como rede de segurança para tudo o que escapa, e para código que os humanos ainda escrevem à mão. A segurança agent-time é a camada à frente deles, a que acompanha a velocidade da coisa que de facto gera o código.

Quais são os principais riscos transversais aos agentes de código de IA?

Os principais riscos são consistentes entre o Claude Code, o Cursor, o GitHub Copilot, o OpenAI Codex e o Windsurf, porque partilham a mesma forma agêntica. Os guias por agente cobrem em detalhe os controlos nativos de cada ferramenta; as classes de risco em si rimam.

• Código gerado inseguro. O agente escreve queries injetáveis, criptografia fraca, autorização em falta e desserialização insegura, porque esses padrões são abundantes nos seus dados de treino. Este é o risco que o enquadramento de infraestrutura ignora por completo.
• Falhas de lógica de negócio. Verificações de propriedade em falta, controlo de acesso quebrado entre tenants, máquinas de estado que permitem transições ilegais. Invisíveis para scanners genéricos, comuns na saída do agente.
• Injeção de prompt, direta e indireta. Instruções hostis escondidas num repositório, numa página web, numa issue ou numa resposta de ferramenta MCP que o agente trata como um comando. OWASP LLM01.
• Ferramentas e servidores MCP com permissões em excesso. Uma ferramenta de base de dados delimitada para ler tudo, um servidor de sistema de ficheiros apontado à diretoria home, uma ferramenta de deploy a guardar credenciais de produção. O envenenamento de ferramentas esconde instruções nas descrições das ferramentas, por isso basta ligar um servidor para orientar o agente.
• Risco de cadeia de suprimentos e de dependências. O agente instala pacotes e corre scripts de configuração como trabalho normal. O typosquatting e a alucinação de pacotes transformam um rotineiro "configura este repositório" em roubo de credenciais.
• Exposição de segredos e de contexto. Contexto local amplo (ficheiros .env, credenciais, endpoints internos) é exposto em logs, código gerado ou num PR que sobrevive à sessão.
• Ações destrutivas. Um agente manipulado corre sudo rm -rf, reescreve uma configuração de CI ou altera infraestrutura, com o acesso que o ambiente lhe concedeu.

Como proteger um agente de código de IA na prática?

Protege-se um agente de código de IA combinando a contenção do tempo de execução com a governação agent-time, mantendo depois o CI como rede de segurança. Privilégio mínimo, ambiente isolado (sandbox), gestão de segredos e revisão humana são o mínimo indispensável. A peça que falta à maioria das stacks é um controlo que viva no prompt e governe o que o agente escreve antes de o escrever.

Na prática, isso significa uma postura de defesa em profundidade com o ponto de controlo puxado para a frente. Delimite as permissões do agente e isole o seu tempo de execução, de modo que um agente orientado tenha um raio de impacto pequeno. Faça a gestão de segredos para que o contexto do agente não seja mais amplo do que a tarefa precisa. Mantenha o SAST e a análise de dependências no CI para tudo o que escapa e para código escrito por humanos. Depois acrescente a camada que de facto acompanha a velocidade do agente: governação dentro do ciclo, onde o agente lê as suas regras de negócio e os seus requisitos de segurança enquanto programa, e um guard interceta chamadas destrutivas antes de dispararem. As quatro camadas agent-time abaixo são a aparência desse controlo.

Que controlos pertencem ao agent-time e quais ao CI?

Os controlos pertencem ao agent-time quando governam uma ação que o agente está prestes a tomar, e ao CI quando são uma rede de segurança sobre o artefacto acabado. A regra geral: se um humano a rever o diff chegasse tarde demais, o controlo tem de correr dentro do ciclo. Se for uma porta final antes do merge ou do deploy, fica no CI.

Leia as duas colunas como parceiras, não rivais. A análise no CI continua a ser o lugar certo para uma verificação final ao nível do artefacto, e deve mantê-la. O agent-time é onde move os controlos que perdem todo o seu valor no momento em que o agente termina e avança. O erro que a SERP comete é financiar apenas o primo de infraestrutura da coluna da direita (sandbox, IAM) deixando o código em si por governar até ao merge.

O VibeDefend é a camada agent-time, empacotada como uma CLI npm gratuita que instala em cerca de cinco segundos. Um comando deteta automaticamente o Claude Code, o Cursor, o OpenAI Codex, o Windsurf e o VS Code Copilot na sua máquina e liga cada um a quatro camadas de governação que correm dentro do ciclo do agente. Sem YAML, sem deploy, sem contentor a construir.

As quatro camadas mapeiam exatamente para o modelo acima. As Regras de Negócio são extraídas da forma como a sua equipa já programa e propostas como regras explícitas de uma linha. As Regras de Segurança carregam os frameworks que os seus auditores esperam e correspondem-nos por edição. O Action Guard interceta chamadas destrutivas antes de dispararem. O Live Findings liga o agente à plataforma de AppSec completa da CybeDefend, os seus scanners (SAST com alcançabilidade, SCA, segredos, IaC e CI/CD) a correr continuamente, de modo que o agente não só escreve código seguro, como tria e corrige as vulnerabilidades que já tem. O modelo de privacidade é a parte que mais importa às equipas de segurança: nada do seu código atravessa a rede. As decisões acontecem localmente, ao lado do agente, e apenas metadados de governação estruturados chegam ao backend, a regra que disparou, o caminho do ficheiro a que apontou, a severidade, um timestamp. Sem código-fonte, sem conteúdo de prompts. Os tenants da EU e dos US são fisicamente separados e escolhidos no momento da instalação, sem caminho entre regiões.

Perguntas frequentes

O que é a segurança agent-time?

A segurança agent-time é impor os seus controlos dentro do ciclo do agente de código de IA, antes de a linha ofensiva ser escrita, em vez de depois de o código chegar a um pull request. O ponto de controlo passa do diff para o prompt: o agente lê as regras que se aplicam enquanto escreve, de modo que o requisito se torna parte da saída. É a resposta aos agentes a entregar código mais depressa do que qualquer humano consegue rever.

Em que é que a segurança de agentes de código de IA difere do ambiente isolado (sandbox)?

O ambiente isolado (sandbox) protege onde o agente corre; a segurança de agentes de código de IA também tem de proteger o que o agente escreve. Um sandbox pode conter perfeitamente o tempo de execução e ainda assim deixar o agente escrever uma query injetável ou saltar uma verificação de autorização, porque o artefacto inseguro não é uma preocupação de tempo de execução. Precisa de ambos: contenção para o raio de impacto, e governação agent-time para o código em si.

Porque é que a análise pós-PR falha para os agentes de IA?

Porque assume que um humano abranda para ler o diff antes do merge, e o agente quebrou essa cadência. Os scanners continuam a encontrar bugs, mas as descobertas acumulam mais depressa do que as equipas conseguem triar, por isso as pessoas ou fazem merge com uma vista de olhos ou juntam tudo num único PR ilegível. O diff deixa de ser uma porta. O controlo tem de se mover para dentro do ciclo, à frente do merge.

A segurança agent-time substitui o SAST e a análise no CI?

Não. O SAST e a análise de dependências mantêm-se no CI como rede de segurança para tudo o que escapa e para código escrito por humanos. A segurança agent-time é a camada à frente deles, acompanhando a velocidade do agente que gera o código. Pense neles como parceiros: o agent-time é a governação de primeira linha da saída do agente, o CI é a porta final ao nível do artefacto.

A que agentes de código de IA se aplica isto?

As mesmas classes de risco e o mesmo modelo agent-time aplicam-se ao Claude Code, ao Cursor, ao GitHub Copilot, ao OpenAI Codex e ao Windsurf, porque partilham uma forma agêntica: leem, escrevem, correm e chamam ferramentas. Os guias por agente cobrem os controlos nativos de cada ferramenta e onde ficam aquém.

Qual é o maior risco de segurança dos agentes de código de IA?

Dois sobressaem. A injeção de prompt é o risco LLM número um da OWASP porque um modelo não consegue separar de forma fiável uma instrução de confiança de uma hostil escondida em dados, e um agente orientado age em vez de apenas responder mal. O mais silencioso são as falhas de lógica de negócio no código gerado: verificações de propriedade em falta e controlo de acesso quebrado que scanners genéricos não conseguem ver e revisores sobrecarregados deixam passar.

Com que rapidez consigo proteger o meu agente de código de IA?

Cerca de cinco segundos para a instalação e aproximadamente um minuto de ponta a ponta. Corra npx -y @cybedefend/vibedefend@latest install, escolha EU ou US, confirme o agente que usa, e coloque um .cybedefend/config.json de uma linha no repositório. O próximo prompt é governado pelas três camadas. O plano gratuito não precisa de cartão, ou pode marcar uma sessão para o correr no seu próprio código.