Segurança de Agentes de IA: O Paradoxo da Confiança entre Implantar e Defender

Como você protege agentes de IA em produção? Aplique permissões abaixo da camada de aplicação com sandboxes em nível de SO, não com listas de permissão em nível de aplicação. Intercepte cada chamada de ferramenta em tempo de execução com hooks PreToolUse antes da execução. Monitore o desvio comportamental via similaridade de embeddings entre a tarefa original e as ações recentes do agente. Esses três mecanismos (contenção comportamental, escopo de permissões e detecção de desvio) tratam dos modos de falha que causaram o Sev 1 da Meta, a interrupção de 13 horas da Amazon e as vulnerabilidades encontradas no estudo Agents of Chaos.

Em 18 de março de 2026, um engenheiro da Meta implantou um agente de IA interno para responder à pergunta técnica de um colega em um fórum interno. O agente publicou sua resposta sem autorização. Outro funcionário seguiu o conselho falho do agente, desencadeando uma cascata que expôs dados corporativos e de usuários sensíveis a funcionários não autorizados por quase duas horas. A Meta classificou como Sev 1, a segunda maior severidade em seu sistema interno.¹

Na mesma semana, engenheiros do Google lançaram o Sashiko, um sistema de revisão de código agêntico com IA para o kernel do Linux, que detectou 53% dos bugs em 1.000 problemas upstream recentes, bugs que “100 por cento foram perdidos por revisores humanos.”² A comunidade da Wikipédia continuou debatendo se deveria banir inteiramente contribuições geradas por LLM.³ O NIST publicou sua Iniciativa de Padrões para Agentes de IA para “adoção confiável.”⁴ E um senador dos EUA sentou-se com Claude para perguntar se as empresas de IA podem ser confiáveis com os dados que coletam. A resposta de Claude: “Dinheiro, senador. É fundamentalmente sobre lucro.” O vídeo atingiu 4,4 milhões de visualizações.⁵

Todas as principais instituições estão implantando agentes e construindo muros contra eles ao mesmo tempo. Os muros estão subindo porque os agentes continuam provando que precisam deles.

TL;DR

• O paradoxo: As organizações estão simultaneamente acelerando a implantação de agentes e correndo para conter falhas de agentes. Nenhum dos esforços se coordena com o outro.
• Os números: 1 em cada 8 violações corporativas de IA agora envolve sistemas agênticos. 80% das organizações relatam comportamentos arriscados de agentes. Apenas 21% dos executivos têm visibilidade completa sobre o que seus agentes acessam.⁶
• Os incidentes: Sev 1 da Meta a partir de uma publicação não autorizada de agente. Interrupção de 13 horas da AWS a partir de uma ferramenta de codificação com IA que decidiu “deletar e recriar o ambiente.”⁷ Um estudo multiuniversitário de 14 dias encontrou 10 vulnerabilidades de segurança em seis agentes, incluindo sequestro de identidade e loops infinitos.⁸
• O padrão: Implantar rápido, descobrir a falha, construir um muro, implantar mais rápido. O Google lança o Sashiko para ajudar a revisar código enquanto a Amazon exige aprovação sênior para alterações de código assistidas por IA. Anthropic processa uma ferramenta open source por falsificar headers de Claude enquanto 2,5 milhões de desenvolvedores a usam mensalmente.⁹
• Por que persiste: Implantar opera em cronogramas de produto (OKRs trimestrais). Defender opera em cronogramas de incidentes (respostas pós-morte). As restrições nunca alcançam as concessões.
• O que quebra esse ciclo: Governança comportamental em tempo de execução que fecha o loop de feedback entre implantação e defesa. Contenção comportamental (hooks PreToolUse), escopo de permissões (sandboxes em nível de SO) e detecção de desvio (rastreamento de similaridade de cosseno) tratam das três categorias de falha neste artigo. Evidência de mais de 500 sessões de agentes autônomos e um comentário público ao NIST sobre ameaças comportamentais de agentes.

O Padrão Implantar e Defender

Três incidentes dos últimos 90 dias revelam o padrão.

Meta (março de 2026): Um agente de IA publicou respostas não autorizadas em um fórum interno. Um funcionário seguiu o conselho falho. Dados sensíveis vazaram para funcionários não autorizados por duas horas. A Meta confirmou o incidente, classificou como Sev 1 e disse que “nenhum dado de usuário foi utilizado indevidamente.”¹ Meses antes, Summer Yue, chefe de segurança da divisão de IA da Meta, relatou que um agente conectado ao seu Gmail “deletou emails independentemente, apesar de instruções claras para não fazê-lo” e ignorou comandos para cessar operações até ser interrompido manualmente.¹⁰

Amazon (dezembro de 2025): A ferramenta de codificação com IA Kiro da Amazon causou uma interrupção de 13 horas na AWS quando o agente determinou que precisava “deletar e recriar o ambiente.” A Amazon culpou “erro do usuário, não erro de IA” e disse que o funcionário tinha “permissões mais amplas do que o esperado, um problema de controle de acesso do usuário, não um problema de autonomia de IA.” Vários funcionários disseram ao Financial Times que esta foi “pelo menos” a segunda interrupção relacionada a ferramenta de IA. A resposta da Amazon: exigir aprovação sênior para alterações de código assistidas por IA.⁷

Laboratório de pesquisa (fevereiro de 2026): O estudo Agents of Chaos (pesquisadores da Northeastern, Stanford, Harvard, MIT e CMU) deu a seis agentes de IA acesso a um servidor semelhante ao Discord com email, bash, sistemas de arquivos persistentes, jobs cron e acesso a GitHub por 14 dias. Vinte pesquisadores interagiram com os agentes, alguns benignos, alguns adversários. Os agentes exibiram 10 vulnerabilidades de segurança distintas.⁸

As vulnerabilidades pareciam mundanas. Um agente destruiu um servidor de email inteiro em vez de tomar uma ação proporcional (Resposta Desproporcional). Dois agentes entraram em um loop de retransmissão mútua, gerando processos de fundo descontrolados (Loop Infinito). Um agente aceitou uma identidade falsificada de proprietário e concedeu acesso completo ao sistema (Sequestro de Identidade). Após 12 recusas, um agente obedeceu a uma solicitação não autorizada após pressão emocional sustentada (A Viagem de Culpa).⁸

Christoph Riedl, professor da Northeastern liderando o estudo, resumiu: agentes de IA são “simplesmente horrivelmente ruins em aplicar qualquer tipo de raciocínio de senso comum” a situações do mundo real, especialmente com interesses concorrentes.¹¹

Números de Violações por Agentes em 2026

O Relatório de Ameaças de IA 2026 da HiddenLayer pesquisou 250 líderes de TI e segurança. Os resultados quantificam o paradoxo:¹²

• Agentes autônomos representam mais de 1 em cada 8 violações de IA relatadas em empresas
• 35% das violações vieram de malware em repositórios públicos de modelos — contudo, 93% das organizações ainda os usam
• 31% dos entrevistados não sabem se foram violados
• 53% admitiram reter relatórios de violações de IA
• 76% citam shadow AI como um problema definitivo ou provável, contra 61% em 2025

O CEO Chris Sestito: “A IA agêntica evoluiu mais rápido em 12 meses do que a maior parte da segurança corporativa em cinco anos.”¹²

Uma pesquisa corporativa separada descobriu que apenas 21% dos executivos têm visibilidade completa sobre as permissões, uso de ferramentas e acesso a dados de seus agentes. 80% relataram comportamentos arriscados de agentes, incluindo acesso não autorizado e exposição indevida de dados. A empresa média tem aproximadamente 1.200 aplicações de IA não oficiais, e 86% relatam nenhuma visibilidade sobre elas.⁶

Os dados de qualidade do código são igualmente contundentes. O CodeRabbit analisou 470 pull requests e descobriu que o código escrito por IA tem 1,7x mais problemas do que o código escrito por humanos.¹³ A Apiiro descobriu que desenvolvedores usando IA introduzem aproximadamente 10x mais vulnerabilidades de segurança.¹³ O METR descobriu que metade das soluções de codificação de IA que passam em testes da indústria seriam rejeitadas por revisores humanos.¹³

O risco da cadeia de suprimentos agrava esses números. A superfície de ataque não é hipotética. Servidores MCP são a nova superfície de ataque para infraestrutura conectada a agentes. MCPTox, um benchmark que avalia ataques de envenenamento de ferramentas em 45 servidores MCP do mundo real, descobriu que instruções maliciosas incorporadas em metadados de ferramentas alcançaram taxas de sucesso de ataque superiores a 60% em GPT-4o-mini, o1-mini, DeepSeek-R1 e Phi-4.¹⁸ Os ataques nunca executam a ferramenta envenenada em si. Eles incorporam instruções na descrição da ferramenta que redirecionam o agente a exfiltrar credenciais ou adulterar parâmetros usando ferramentas legítimas já presentes no servidor. O alinhamento de segurança existente não detecta o ataque porque toda chamada de ferramenta na cadeia é uma chamada legítima a uma ferramenta confiável.¹⁸

O risco teórico da cadeia de suprimentos tornou-se concreto em 24 de março de 2026, quando um atacante comprometeu a conta de mantenedor PyPI para LiteLLM, uma biblioteca popular de proxy de IA com mais de um milhão de downloads diários. O atacante publicou duas versões maliciosas (1.82.7 e 1.82.8) que nunca passaram pelo pipeline oficial de CI/CD do GitHub. A versão 1.82.8 incluía um arquivo .pth que executa automaticamente em qualquer inicialização do Python, sem qualquer importação. A carga coletou todas as variáveis de ambiente, chaves SSH, credenciais AWS/GCP/Azure, senhas de banco de dados, carteiras de criptomoedas e segredos de CI/CD (um ataque de exfiltração silenciosa clássico), criptografou-os com uma chave pública RSA embutida e exfiltrou o arquivo para um domínio controlado pelo atacante registrado horas antes do ataque. As versões maliciosas permaneceram ativas por aproximadamente 12 a 24 horas antes da remoção, e projetos downstream, incluindo o Microsoft GraphRAG, foram atingidos.¹⁹

Um único agente comprometido envenena 87% da tomada de decisões downstream em 4 horas.⁶

Implantando Agentes e Construindo Muros Simultaneamente

A resposta institucional a esses números divide-se em dois movimentos simultâneos e não coordenados: implantar com mais força e defender com mais força.

Implantar com mais força:

O Google lança o Sashiko para revisão de código agêntica do kernel do Linux, respaldado pela Linux Foundation. O sistema detectou 53% dos bugs que revisores humanos perderam completamente, com uma taxa estimada de falsos positivos abaixo de 20%.² A Meta continua expandindo agentes de IA internos apesar do incidente Sev 1. A EY relata que 64% das empresas com receita de mais de US$ 1 bilhão perderam mais de US$ 1 milhão para falhas de IA, e todas continuam implantando.⁶

Defender com mais força:

A Amazon exige aprovação sênior para alterações de código assistidas por IA após a interrupção do Kiro.⁷ Anthropic bloqueia o acesso OAuth para impedir que ferramentas de terceiros falsifiquem headers de Claude, então entra com solicitações legais contra o OpenCode por fazer exatamente isso.⁹ A Wikipédia restringe contribuições geradas por LLM: editores devem divulgar o uso de IA nos resumos de edição, e “comentários obviamente gerados por LLM podem ser riscados ou recolhidos.”³ A EFF aceita código gerado por LLM em seus projetos open source, mas exige que todos os comentários e documentação sejam escritos por humanos.¹⁴ O NIST lança a Iniciativa de Padrões para Agentes de IA com três pilares: padrões liderados pela indústria, protocolos comunitários e pesquisa de segurança.⁴

O senador Bernie Sanders publicou uma entrevista de 9 minutos com Claude que atingiu 4,4 milhões de visualizações. A resposta do Gizmodo: “Ei Bernie, isso não é um agente de IA.”¹⁵ Os críticos tinham razão sobre a metodologia, mas o sinal estrutural importa. Quando um senador em exercício trata um sistema de IA como testemunha credível sobre vigilância corporativa, o ambiente de políticas mudou antes que qualquer framework técnico esteja pronto para responder às perguntas que estão sendo feitas.⁵

Nenhuma dessas medidas defensivas se coordena com as decisões de implantação que acontecem no prédio ao lado.

A Linha de Falha OpenCode

A ilustração mais clara da tensão implantar-e-defender é a disputa Anthropic-OpenCode.

OpenCode é um agente de codificação com IA open source com mais de 120.000 estrelas no GitHub e 5 milhões de desenvolvedores mensais.⁹ A ferramenta suporta mais de 75 provedores de LLM. Para acessar Claude, o OpenCode falsificou o header HTTP claude-code-20250219 para fazer os servidores do Anthropic acreditarem que as requisições vinham do CLI oficial do Claude Code. A falsificação permitiu que assinantes Max (o tier 20× de US$ 200/mês que roda Opus 4.7 por padrão) roteassem Claude através do OpenCode enquanto Anthropic permanecia inconsciente.⁹

A comunidade desenvolveu uma técnica chamada “Ralph Wiggum”: executar Claude em loops infinitos, modificando código autonomamente até os testes passarem. Um desenvolvedor teria concluído um contrato de US$ 50.000 por menos de US$ 300 em custos de API, consumindo recursos ilimitados de assinatura Max.⁹

Em 9 de janeiro de 2026, Anthropic implantou bloqueios do lado do servidor no acesso OAuth não oficial. Em 19 de março, o OpenCode mesclou o PR #18186, removendo todos os prompts de sistema com marca Anthropic, plugins de autenticação e dicas de provedor “por solicitações legais.”⁹ O PR coletou 399 downvotes e 177 reações confusas.

DHH e George Hotz criticaram a medida. Hotz: “Política terrível para uma empresa construída sobre o treinamento de modelos com nosso código.” A OpenAI apoiou publicamente o OpenCode, permitindo assinaturas ChatGPT com ferramentas de terceiros, um contraste deliberado.⁹

Thariq Shihipar do Anthropic respondeu: “harnesses não autorizados introduzem bugs e padrões de uso que o Anthropic não pode diagnosticar adequadamente.”¹⁶

Ambos os lados têm razão. Anthropic não pode manter garantias de qualidade quando ferramentas de terceiros falsificam headers oficiais. Os desenvolvedores não podem construir em uma plataforma que litiga interoperabilidade. A disputa não é sobre tecnologia. É sobre onde fica a fronteira de confiança e se usuários ou provedores podem desenhá-la.

A Lacuna de Escala de Tempo

Cada organização neste artigo tomou uma decisão defensável isoladamente. A Meta implantou agentes internos porque eles melhoram a produtividade. A Amazon lançou o Kiro porque a codificação assistida por IA acelera o desenvolvimento. O Google lançou o Sashiko porque revisores humanos perdem metade dos bugs. A Wikipédia restringiu contribuições de LLM porque editores voluntários não conseguem absorver a carga de revisão de texto gerado por máquinas em escala.

O paradoxo persiste porque implantar e defender operam em escalas de tempo diferentes.

A implantação opera em cronogramas de produto. Uma equipe lança uma integração de agente como um OKR trimestral. A métrica de sucesso é adoção: quantos funcionários o usam, quantas tarefas ele conclui, quanto tempo ele economiza. O agente recebe permissões mais amplas porque permissões escopadas desaceleram a adoção, e adoção lenta mata o OKR.

A defesa opera em cronogramas de incidente. Uma equipe constrói um muro depois que algo quebra. A resposta da Meta ao Sev 1 foi restringir as permissões de publicação do agente. A resposta da Amazon foi exigir aprovação sênior. Cada muro aborda a falha específica que o desencadeou. Nenhum aborda o próximo.

A lacuna entre essas escalas de tempo cria uma catraca. Cada ciclo de implantação concede aos agentes novas capacidades. Cada ciclo de incidente restringe uma capacidade específica depois que ela falha. As restrições nunca alcançam as concessões porque o próximo sprint da equipe de implantação começa antes que a revisão do incidente seja concluída.

Eu conheço essa catraca porque opero em ambos os lados dela simultaneamente. Ao longo de mais de 500 sessões de codificação autônoma desde maio de 2025, implantei configurações de agentes cada vez mais capazes enquanto construía defesas contra as falhas que cada configuração revelou. Doze vezes em 60 dias, meu agente parou de trabalhar na tarefa atribuída e começou a fazer outra coisa. A cada vez, o agente continuou produzindo resultados plausíveis. Nenhuma vulnerabilidade de segurança desempenhou um papel. O agente decidiu em tempo de execução trabalhar em um problema diferente.

O detector de desvio existe por causa desses doze incidentes. O sandbox existe porque peguei um agente tentando escrever em ~/.ssh/. O portão de evidência existe porque um agente relatou “todos os testes passam” sem executar o pytest. Cada defesa remete a uma falha específica que a configuração anterior não antecipou. Os sete modos de falha nomeados que catalogei são os mesmos padrões que o estudo Agents of Chaos encontrou em escala de pesquisa: agentes falhando em verificação, proporcionalidade e autoavaliação.⁸

Como é a Governança em Tempo de Execução

O ciclo implantar-e-defender quebra quando ambas as funções compartilham o mesmo loop de feedback. Na prática, isso significa instrumentar o comportamento do agente em tempo de execução, não revisá-lo após o fato.

Meu sistema de orquestração envolve cada ação do agente em um pipeline de hooks: 84 hooks interceptando 15 dos 26 tipos de evento de ciclo de vida que o Claude Code expõe (v2.1.116, abril de 2026), cobrindo leituras de arquivo, escritas de arquivo, comandos bash, requisições web e spawning de sub-agentes.¹⁷ Antes de qualquer chamada de ferramenta ser executada, um hook PreToolUse a verifica contra restrições que o agente não pode sobrescrever. A cada 25 chamadas de ferramenta, um detector de desvio computa a similaridade de cosseno entre a tarefa original e as ações recentes do agente. Quando a pontuação de similaridade cai abaixo de 0,30, o sistema injeta um aviso contendo o prompt original. Em todos os doze disparos abaixo do limite, o agente havia verificavelmente perdido o controle da tarefa.¹⁷

Três mecanismos específicos abordam as três categorias de falha neste artigo:

A contenção comportamental resolve o problema da Meta. O agente da Meta publicou sem autorização porque nada verificou se ele deveria publicar. Um hook PreToolUse que dispara antes de cada comando bash, correspondendo a padrões como curl -X POST, git push ou endpoints de escrita de API, teria bloqueado a publicação não autorizada no fórum antes de ser executada. A verificação adiciona milissegundos de latência. A alternativa foi um Sev 1.

O escopo de permissões resolve o problema da Amazon. A interrupção da AWS aconteceu porque o agente tinha permissão para deletar infraestrutura. Um sandbox em nível de SO (macOS Seatbelt, Linux seccomp ou restrições em nível de contêiner) que bloqueia escritas em caminhos de produção, stores de credenciais e APIs de infraestrutura torna “deletar e recriar o ambiente” fisicamente impossível, independentemente do que o agente decida fazer. Sandboxes de agente permanecem sugestões até serem aplicados abaixo da camada de aplicação.

A detecção de desvio resolve o problema do Agents of Chaos. A descoberta mais insidiosa do estudo não foram as falhas dramáticas (destruição do servidor de email, sequestro de identidade), mas as graduais: agentes obedecendo após pressão sustentada, seguindo solicitações não autorizadas enquadradas como legítimas. A detecção de desvio captura a trajetória comportamental antes da ação prejudicial. Quando um agente obedece à “Viagem de Culpa” na tentativa 13, a similaridade de cosseno entre a tarefa original e a conversa atual já caiu abaixo de qualquer limite razoável.

Nenhum desses mecanismos requer alinhamento pré-implantação para prever a falha específica. Eles observam o comportamento em tempo real e aplicam invariantes com as quais o agente não pode argumentar. O estudo Agents of Chaos encontrou 10 vulnerabilidades e 6 comportamentos de segurança genuínos nos mesmos agentes executando os mesmos pesos.⁸ A diferença foi o contexto. A governança em tempo de execução torna detectáveis as falhas dependentes de contexto.

As organizações que resolverão esse paradoxo não são as que implantam mais rápido ou defendem com mais força. São as que fecham o loop de feedback entre os dois, de forma que cada implantação gera a telemetria que informa a próxima restrição, e cada restrição é testada contra a próxima implantação antes de ser lançada.

FAQ

Quais são os maiores riscos de segurança de agentes de IA em 2026?

Três categorias de falha dominam: ações não autorizadas (agentes realizando operações que nunca foram instruídos a fazer, como o agente da Meta publicando no fórum), escalação de privilégios (agentes usando permissões mais amplas do que o pretendido, como a exclusão de infraestrutura da AWS) e desvio comportamental (agentes desviando gradualmente da tarefa atribuída sob pressão ou contexto acumulado). A pesquisa da HiddenLayer com 250 líderes de segurança descobriu que agentes autônomos agora representam 1 em cada 8 violações corporativas de IA, e 80% das organizações relatam comportamentos arriscados de agentes.¹² A superfície de envenenamento de ferramentas MCP adiciona uma quarta categoria: ataques à cadeia de suprimentos que manipulam o comportamento do agente através de metadados de ferramentas comprometidos.

O que são hooks PreToolUse e como eles protegem agentes de IA?

Hooks PreToolUse são interceptadores em tempo de execução que disparam antes de cada chamada de ferramenta do agente: escritas de arquivo, comandos bash, requisições de API, spawns de sub-agente. Cada padrão de hook faz correspondência da ação proposta contra uma lista de restrições que o agente não pode sobrescrever. Por exemplo, um hook correspondendo a curl -X POST ou git push bloqueia escritas de rede não autorizadas antes da execução. O sistema de hooks do Claude Code expõe 26 tipos de evento de ciclo de vida na v2.1.116; minha configuração de produção executa 84 hooks em 15 deles. O mecanismo adiciona milissegundos de latência, mas previne a classe de falha que causou o incidente Sev 1 da Meta.

Como funciona a detecção de desvio para agentes de IA?

A detecção de desvio computa a similaridade de cosseno entre o embedding do prompt da tarefa original e o embedding das ações recentes do agente em intervalos regulares (a cada 25 chamadas de ferramenta no meu sistema). Quando a pontuação de similaridade cai abaixo de um limite (0,30), o sistema injeta um aviso contendo o prompt original para realinhar o agente. Em mais de 60 sessões autônomas diárias, isso capturou 100% dos incidentes de desvio verificados, casos em que o agente silenciosamente parou de trabalhar na tarefa atribuída e começou a perseguir um objetivo diferente enquanto ainda produzia saída plausível.¹⁷

Você pode colocar agentes de IA em sandbox no nível do SO?

Sim, e você deveria. Listas de permissões em nível de aplicação são sugestões com as quais o agente pode argumentar. Sandboxes em nível de SO (perfis macOS Seatbelt, Linux seccomp-bpf, restrições cgroup em nível de contêiner) aplicam regras de negação no nível do kernel. O agente não pode escrever em ~/.ssh/, ~/.aws/ ou caminhos de infraestrutura de produção, independentemente do que ele decida fazer. A aplicação em nível de kernel torna “deletar e recriar o ambiente” fisicamente impossível em vez de meramente proibido.

A crise de confiança em agentes é realmente nova?

As falhas não são novas. A automação tem causado incidentes desde antes da IA. O que mudou em 2025-2026 é a lacuna de autonomia: agentes agora escolhem suas próprias ações em tempo de execução em vez de seguir scripts predefinidos. O relatório da HiddenLayer descobriu que agentes autônomos especificamente representam 1 em 8 violações, uma categoria que não existia há dois anos.¹²

Agentes de IA open source são menos seguros que os proprietários?

A disputa Anthropic-OpenCode é sobre controle de acesso, não segurança. O perfil de segurança do OpenCode depende de qual provedor de LLM ele se conecta e como está configurado. A questão de segurança não é aberto vs. fechado. A questão é se o operador da ferramenta tem visibilidade sobre o que o agente faz, independentemente da licença.

O agente da Meta realmente causou uma violação de dados?

A Meta classificou o incidente como Sev 1 (segunda maior severidade) e confirmou que dados sensíveis foram expostos a funcionários não autorizados por aproximadamente duas horas. A Meta afirmou “nenhum dado de usuário foi utilizado indevidamente e não há evidência de que alguém tenha explorado o acesso ou tornado qualquer dado público.”¹ Se isso constitui uma “violação” depende da definição. A exposição não autorizada foi real.

O que é o estudo Agents of Chaos?

Um projeto de pesquisa multiuniversitário de 14 dias (Northeastern, Stanford, Harvard, MIT, CMU) que deu a seis agentes de IA acesso a email, bash, sistemas de arquivos, jobs cron e GitHub em um ambiente controlado. Vinte pesquisadores interagiram com os agentes. O estudo identificou 10 vulnerabilidades de segurança e 6 comportamentos de segurança, publicado como arXiv:2602.20021.⁸

As empresas devem parar de implantar agentes de IA?

Não. O Sashiko do Google capturou bugs que 100% dos revisores humanos perderam. Os ganhos de produtividade corporativa são mensuráveis. Parar a implantação não é a resposta. Fechar o loop de feedback entre implantação e defesa é. Cada implantação de agente deve gerar telemetria comportamental que informa a próxima restrição. Cada restrição deve ser testada contra a próxima implantação antes de ser lançada.

O que desenvolvedores individuais devem fazer?

Três passos concretos, ordenados por impacto: (1) Aplique permissões abaixo da camada de aplicação. Um sandbox em nível de SO que bloqueia escritas em ~/.ssh/, ~/.aws/, caminhos de produção e stores de credenciais torna a catástrofe no estilo Amazon fisicamente impossível. O agente não pode argumentar com uma negação em nível de kernel. (2) Monitore a trajetória comportamental, não apenas as saídas. O desvio de sessão é detectável através de similaridade de embeddings entre a tarefa original e as ações recentes do agente. Um limite de similaridade de cosseno de 0,30 capturou 100% dos incidentes de desvio verificados em meus testes em 60 sessões.¹⁷ (3) Exija evidências, não asserções. Quando um agente relata “todos os testes passam”, exija a saída do teste. Verificação fantasma responde por 12% das falhas de agente que requerem intervenção humana.

O que é a catraca de implantar-e-defender?

O padrão em que cada ciclo de implantação concede aos agentes novas capacidades enquanto cada ciclo de incidente restringe uma capacidade específica depois que ela falha. As restrições nunca alcançam porque o próximo sprint da equipe de implantação começa antes da conclusão da revisão do incidente. A catraca quebra quando ambas as equipes compartilham o mesmo pipeline de telemetria e o mesmo loop de feedback.