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 que limita o que um agente de código autónomo produz e executa, na geração, na execução de comandos e nas chamadas de ferramentas, em vez de proteger apenas a caixa onde ele 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 teu nome.

A expressão é muitas vezes entendida de forma demasiado estreita. A maior parte das recomendações publicadas trata-a como um problema de infraestrutura: pôr o agente num ambiente isolado (sandbox), delimitar o seu papel de IAM, limitar o tráfego de saída, controlar as permissões. Esses controlos são necessários e não estamos a pô-los em causa. Mas respondem a outra pergunta. O ambiente isolado (sandbox) decide aquilo em que o agente pode tocar. Não diz nada 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 expor 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 age em vez de sugerir. Um assistente de IDE tradicional propõe uma sugestão que uma pessoa decide colar. Um agente lê ficheiros que ninguém lhe indicou, corre comandos que ninguém escreveu, edita código por toda a árvore e chama ferramentas ligadas há semanas. O raio de impacto já não se limita a um bloco de código.

Há duas mudanças que agravam isto. A primeira é a autonomia: o agente pode ser manipulado. Como um modelo de linguagem não consegue distinguir com fiabilidade uma instrução legítima de uma maliciosa escondida nos dados, um atacante pode esconder instruções num ficheiro, numa página web, numa issue ou na resposta de uma ferramenta, e o agente cumpre-as. É a injeção de prompt indireta, e é o risco número um da OWASP para aplicações LLM há três anos seguidos. Um assistente manipulado responde mal; um agente manipulado age.

A segunda mudança é a velocidade, e é a que a maioria das equipas subestima. O pull request funcionava como barreira de segurança porque assentava no ritmo humano. O agente não trabalha ao ritmo humano. Quando uma única sessão entrega numa tarde mais código do que um revisor lê numa semana, qualquer controlo que exista só no PR está a rever o passado, não a evitá-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 pensada para o ritmo humano e o agente rebentou com esse ritmo. O SAST, o SCA e o revisor humano atuam todos sobre o mesmo artefacto, o diff, e todos partem do princípio de que alguém abranda para o ler antes do merge. Quando o agente vai mais depressa do que o revisor, essa premissa cai.

O problema não é os scanners deixarem de encontrar bugs. Continuam a encontrá-los. O problema é de tempo e de volume. Quando um scanner assinala uma injeção no diff já integrado, o agente já escreveu a linha, passou à frente, construiu três funcionalidades por cima, e um programador tem uma fila de descobertas para triar que cresce mais depressa do que alguém a consegue esvaziar. As equipas reagem de duas formas previsíveis, ambas más: umas fazem merge do que o agente produz depois de uma vista de olhos, outras juntam tudo num PR gigante que ninguém lê de ponta a ponta. Seja como for, o diff deixou de ser uma barreira. É um registo do que já aconteceu.

Há também um desajuste mais profundo. Os erros mais graves de um agente de IA 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 se acumula quando não devia, uma transição de estado que nunca deveria ter sido possível. Um scanner que não conhece o teu domínio não as vê, e um revisor afogado no que o agente produz também não as apanha. O controlo tem de conhecer as tuas 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 aplicar os teus controlos dentro do ciclo do agente de código de IA, antes de a linha problemática ser escrita, e não 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 relevantes enquanto escreve o código, e o requisito passa a fazer parte do resultado, em vez de ser uma caixa a assinalar na altura da auditoria.

É a resposta natural ao problema do ritmo. Se o agente entrega mais depressa do que consegues rever, não ganhas por rever com mais afinco. Ganhas pondo a regra nas mãos do agente antes de ele agir. Em concreto, a segurança agent-time liga-se à sessão e às 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 em causa; antes de um comando destrutivo disparar, interceta-o. Nada fica à espera do merge.

O pull request era um ponto de controlo porque uma pessoa o lia. Agora o ponto de controlo é o prompt, porque o agente o ouve. A segurança agent-time é a camada que põe o ouvido do agente do teu lado.

Isto não substitui os teus scanners. O SAST e o SCA continuam a ter lugar no CI, como rede de segurança para tudo o que escapa e para o código que as pessoas ainda escrevem à mão. A segurança agent-time é a camada que fica à frente deles, a que acompanha a velocidade de quem gera de facto o código.

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

Os principais riscos são os mesmos no Claude Code, no Cursor, no GitHub Copilot, no OpenAI Codex e no Devin Desktop, porque todos funcionam como agentes da mesma maneira. Os guias por agente tratam em detalhe os controlos nativos de cada ferramenta; as classes de risco, essas, repetem-se. O mais recente, o Google Antigravity, segue o mesmo padrão. Para onde vai o teu código também depende de cada agente, e o Claude Code, o Codex e o Cursor respondem cada um à sua maneira.

• Código gerado inseguro. O agente escreve queries injetáveis, criptografia fraca, autorização em falta e desserialização insegura, porque esses padrões abundam nos dados com que foi treinado. É o risco que a visão centrada na 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 os scanners genéricos, frequentes no código 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 uma ordem. OWASP LLM01. Os ficheiros de regras do próprio repositório trazem o mesmo ataque: vê a injeção por ficheiro de instruções.
• Ferramentas e servidores MCP com permissões a mais. Uma ferramenta de base de dados com acesso de leitura a tudo, um servidor de sistema de ficheiros apontado à diretoria home, uma ferramenta de deploy que guarda credenciais de produção. O envenenamento de ferramentas esconde instruções nas descrições das ferramentas, por isso basta ligar um servidor para desviar o agente.
• Risco de cadeia de fornecimento e de dependências. O agente instala pacotes e corre scripts de configuração como parte do trabalho normal. O typosquatting e a alucinação de pacotes transformam um banal "configura este repositório" em roubo de credenciais. A variante do pacote alucinado tem nome: slopsquatting.
• Exposição de segredos e de contexto. Um contexto local amplo (ficheiros .env, credenciais, endpoints internos) acaba exposto em logs, em 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 deu. As flags que retiram o último ponto de controlo estão explicadas para o Codex, e uma sandbox não resolve tudo, como mostram as fugas de sandbox dos agentes.

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

Proteges um agente de código de IA juntando a contenção do tempo de execução à governação agent-time, e mantendo 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. O que falta à maioria das stacks é um controlo que exista no prompt e governe o que o agente escreve antes de o escrever. Um ficheiro de regras não faz esse trabalho: a documentação da Anthropic sobre a memória diz que o Claude trata o CLAUDE.md como contexto, não como configuração imposta (um ficheiro de regras face ao VibeDefend).

Na prática, isso quer dizer defesa em profundidade, com o ponto de controlo puxado para a frente. Delimita as permissões do agente e isola o seu tempo de execução, para que um agente manipulado tenha um raio de impacto pequeno. Gere os segredos de modo que o contexto do agente não seja mais amplo do que a tarefa exige. Mantém o SAST e a análise de dependências no CI, para tudo o que escapa e para o código escrito por pessoas. Depois acrescenta a camada que acompanha de facto a velocidade do agente: governação dentro do ciclo, em que o agente lê as tuas regras de negócio e os teus requisitos de segurança enquanto programa, e um guard interceta as chamadas destrutivas antes de dispararem. As quatro camadas agent-time abaixo mostram como é esse controlo.

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

Um controlo pertence ao agent-time quando governa uma ação que o agente está prestes a tomar, e ao CI quando é uma rede de segurança sobre o artefacto acabado. A regra geral: se uma pessoa a rever o diff já chegasse tarde, o controlo tem de correr dentro do ciclo. Se for uma última barreira antes do merge ou do deploy, fica no CI.

Lê as duas colunas como complementares, não como rivais. A análise no CI continua a ser o sítio certo para uma verificação final do artefacto, e deves mantê-la. O agent-time é para onde levas os controlos que perdem todo o valor assim que o agente termina e passa à frente. O erro que se vê nos resultados de pesquisa é investir só no primo de infraestrutura da coluna da direita (sandbox, IAM) e deixar o código em si sem governação até ao merge.

O VibeDefend é a camada agent-time, distribuída como uma CLI npm gratuita. Um comando deteta automaticamente o Claude Code, o Cursor, o OpenAI Codex, o Devin Desktop e o VS Code Copilot na tua 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 para construir.

As quatro camadas correspondem exatamente ao modelo acima. As Regras de Negócio são extraídas da forma como a tua equipa já programa e propostas como regras explícitas de uma linha. As Regras de Segurança carregam os frameworks que os teus auditores esperam e associam-nos a cada edição. No Claude Code, no Cursor e no Codex, o Action Guard interceta as chamadas destrutivas antes de dispararem. O Live Findings liga o agente à plataforma de segurança do código da CybeDefend, com os seus scanners (SAST com alcançabilidade, SCA, segredos, IaC e CI/CD) a correr continuamente, e o agente não só escreve código seguro como tria e corrige as vulnerabilidades que já tens. Para onde vai o código é a primeira pergunta das equipas de segurança, por isso aqui fica a resposta, sem rodeios. Os action guards decidem no portátil do programador, antes de um comando correr. Para servir as regras que se aplicam à linha que está a ser escrita, o VibeDefend envia um excerto curto desse código para o backend da CybeDefend; a análise feita antes do commit envia os ficheiros alterados; as regras de negócio são extraídas pela plataforma CybeDefend a partir do repositório que ligares. Tudo isto vai para a região da UE ou dos EUA escolhida na instalação; as duas são fisicamente separadas, sem caminho entre regiões, e o código nunca é usado para treinar um modelo, nem o nosso nem o de um subcontratante.

Perguntas frequentes

O que é a segurança agent-time?

A segurança agent-time é aplicar os teus controlos dentro do ciclo do agente de código de IA, antes de a linha problemática ser escrita, e não 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 aplicáveis enquanto escreve, e o requisito passa a fazer parte do resultado. É a resposta a agentes que entregam código mais depressa do que qualquer pessoa 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 o sítio onde o agente corre; a segurança de agentes de código de IA tem também de proteger o que o agente escreve. Uma sandbox pode conter na perfeição o tempo de execução e mesmo assim deixar o agente escrever uma query injetável ou saltar uma verificação de autorização, porque o artefacto inseguro não é um problema de tempo de execução. Precisas 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 parte do princípio de que alguém abranda para ler o diff antes do merge, e o agente rebentou com esse ritmo. Os scanners continuam a encontrar bugs, mas as descobertas acumulam-se mais depressa do que as equipas as conseguem triar, e as pessoas acabam por fazer merge depois de uma vista de olhos ou por juntar tudo num único PR ilegível. O diff deixa de ser uma barreira. O controlo tem de passar para dentro do ciclo, antes 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 ficam no CI como rede de segurança para tudo o que escapa e para o código escrito por pessoas. A segurança agent-time é a camada que fica à frente deles e acompanha a velocidade do agente que gera o código. Vê-os como complementares: o agent-time é a governação de primeira linha do que o agente produz, o CI é a última barreira 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 Devin Desktop, porque todos funcionam como agentes: leem, escrevem, executam e chamam ferramentas. Os guias por agente cobrem os controlos nativos de cada ferramenta e os pontos em que ficam aquém. Que editor traz cada controlo ligado por omissão é o que compara a nossa comparação de seis editores de código com IA.

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

Há dois que se destacam. A injeção de prompt é o risco LLM número um da OWASP, porque um modelo não consegue separar com fiabilidade uma instrução legítima de uma hostil escondida nos dados, e um agente manipulado age em vez de se limitar a 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 os scanners genéricos não veem e que os revisores sobrecarregados deixam passar.

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

Basta um comando. Corre npx -y @cybedefend/vibedefend@latest install, escolhe EU ou US, confirma o agente que usas e põe um .cybedefend/config.json de uma linha no repositório. O prompt seguinte já é governado pelas quatro camadas. O plano gratuito não pede cartão, ou podes marcar uma sessão para o correr no teu próprio código. Para um guia prático passo a passo, vê como proteger uma aplicação inteira em 5 minutos.