Caderno técnico do modelo TRAMA. Como fechar cada uma das seis lacunas de cobertura de engenharia com técnicas de IA que funcionam — com os prompts, o harness, as classes de modelo, as chaves de junção entre logs e vulnerabilidades, o índice de risco que decide a ação, e o capítulo que quase todo programa de segurança subestima: o insider e o mercado de credenciais.
PRINCÍPIO ORDENADOR
Pedir a um agente que seja seguro não é o mesmo que garantir que ele seja.
Antes de qualquer técnica, uma classificação. Sem ela, toda mitigação com IA vira promessa não verificável — e é exatamente assim que a maioria dos programas de “IA na segurança” falha em auditoria.
A engenharia de harness já resolveu esse problema de nomenclatura, e a solução se aplica sem alteração à defesa. Controles se distinguem em dois eixos. No primeiro, guias (controles de antecipação) orientam o modelo antes de ele agir, enquanto sensores (controles de retorno) observam o resultado depois e sinalizam erro. No segundo, controles computacionais são determinísticos, rápidos e rodam em CPU — testes, linters, verificadores de tipo, análise estrutural, em milissegundos e com resultado confiável — enquanto controles inferenciais dependem de análise semântica e julgamento de modelo: mais lentos, mais caros, não determinísticos, mas capazes de julgamento que nenhuma regra expressa.
A regra que este caderno adota, e que deveria estar escrita na parede de qualquer equipe que automatiza defesa com IA: um controle inferencial nunca é o único portão. Ele enriquece, prioriza, explica e propõe. Quem bloqueia, reprova ou contém é sempre um controle computacional — porque só ele é reproduzível diante de um auditor e só ele tem latência previsível.
Uma equipe que escalava um protótipo construído por conversa com o agente encontrou recomendações para tornar buckets de armazenamento públicos e conceder permissões de token muito além do necessário. A conclusão publicada é direta: instruir o agente a ser seguro não equivale a garantir que ele seja, e prompt para desenvolvimento guiado por testes não equivale a impor limiar de cobertura na ferramenta de build.
MITIGAÇÃO
As seis lacunas, com a técnica que fecha cada uma.
Para cada lacuna: o que a IA faz de fato, qual controle determinístico tem autoridade para reprovar, e qual número mostra se funcionou. Nenhuma linha depende apenas de julgamento de modelo.
| Lacuna | O que a IA faz | Quem reprova (computacional) | Métrica de eficácia |
|---|---|---|---|
| 1 · Verificação | Gera testes de restrição e de caracterização a partir do contrato; avaliador adversarial tenta quebrar o código sem quebrar o teste; revisão semântica de deriva de intenção | Análise estática, teste de mutação, limiar de cobertura no build, verificação de conformidade ao envelope | Escore de mutação e taxa de escape de defeito por 1.000 linhas geradas |
| 2 · Identidade não humana | Classifica o segredo encontrado, infere o dono provável pelo grafo de commits e chamados, propõe o caminho de rotação e o escopo mínimo | Varredura de segredo em pré-commit e no histórico, bloqueio de push, emissão de credencial de vida curta por identidade de carga | Idade mediana da credencial, percentual de identidades com dono atribuído, tempo entre detecção e revogação |
| 3 · Remediação | Triagem com cruzamento de alcançabilidade, exploração e contrato; gera a correção e o teste de regressão; escreve o registro de exceção com justificativa | Grafo de chamadas e análise de composição, portão de política no pipeline, prazo por faixa de risco imposto pelo build | Percentual do backlog tratado por fluxo automatizado, tempo até correção por faixa de risco |
| 4 · Fronteira e cadeia | Avalia pacote novo antes da adoção, detecta nome plausível mas inexistente, resume mudança de comportamento entre versões | Registro interno com atraso de adoção, verificação de proveniência e assinatura, negação de dependência fora do registro | Percentual de dependências vindas do registro interno, incidentes de pacote alucinado bloqueados |
| 5 · Intenção | Deriva o contrato de serviços legados a partir de código, configuração e telemetria observada; mantém contrato e código sincronizados | Compilador de contrato: o artefato precisa gerar política, detecção e teste válidos, ou o serviço não é considerado coberto | Cobertura de intenção e latência de sincronia |
| 6 · Governança da IA interna | Varre registros de conversa de agentes procurando padrão perigoso; classifica dado sensível em conteúdo livre antes de ele chegar ao modelo | Mediação obrigatória de saída, esquema de ferramenta estreito, negação de comando bruto de nuvem, isolamento por classe de risco | Percentual de tráfego de IA que passa por mediação, ações de agente negadas por política |
Lacuna 1 — o teste que o agente não consegue burlar
O erro clássico é pedir ao modelo que gere testes para o próprio código. Ele gera testes que passam. A técnica que funciona inverte a ordem e o autor: os testes de restrição — entradas e saídas únicas que delimitam o que o agente tem permissão de gerar — nascem do contrato, antes do código, e são escritos por um agente diferente. Depois, sobre código desconhecido ou gerado, roda-se a sequência cobertura, sondagem adversarial e teste de mutação: primeiro verifica-se a cobertura, depois um agente tenta quebrar o código sem quebrar a suíte, e só se essa sondagem tiver sucesso vale a pena aplicar mutação.
Há um número que justifica o esforço: a taxa média de aprovação em segurança de código gerado está em 56% e não se moveu em quatro janelas de medição, enquanto a aprovação sintática beira 100%. O modelo não vai resolver isso sozinho — a verificação precisa ser externa a ele.
Lacuna 2 — a credencial que ninguém sabe de quem é
O número que reorganiza a prioridade não é o volume de segredos, é a razão entre identidades. Estimativas de 2026 colocam identidades não humanas superando as humanas em proporções que vão de 45 para 1 até 144 para 1 em ambientes nativos de nuvem, com 47% delas sem rotação de credencial há mais de um ano e cerca de 8% sem dono identificável em sistemas de RH. O levantamento associado ao ciclo de 2026 aponta ainda que 31% das violações relacionadas a identidade se originaram de uma credencial não humana que ninguém da equipe atual reconhecia como sua.
A IA é útil aqui num ponto muito específico e nada glamoroso: atribuição de dono. Dado um segredo encontrado, o modelo cruza histórico de commits, chamados, canais internos e configuração de infraestrutura para propor o responsável provável e o escopo mínimo — trabalho que humanos não fazem porque é tedioso e que regras não fazem porque exige leitura de contexto. O portão continua determinístico: sem dono atribuído em N dias, a credencial é rotacionada e o serviço quebra em ambiente de teste antes de quebrar em produção.
Lacuna 3 — parar de corrigir a coisa errada primeiro
A prioridade por severidade teórica está estruturalmente desalinhada com o risco real. Apenas cerca de 2,3% das vulnerabilidades com nota 7 ou mais chegam a sofrer tentativa de exploração, enquanto 28% das que são efetivamente exploradas carregam nota apenas média. Pior: vulnerabilidades com alta probabilidade de exploração levam em média 109 dias para serem corrigidas, contra 76 dias das de baixa probabilidade — a fila está literalmente invertida.17
A correção disso não é um modelo melhor, é uma junção melhor. É o assunto da seção sobre o índice de exposição, adiante.
Lacuna 6 — proteger o próprio programa de defesa
O ranking de riscos de aplicações com modelos de linguagem para 2026 manteve injeção de prompt e divulgação de informação sensível nas duas primeiras posições, e promoveu agência excessiva do sexto para o terceiro lugar. Para um programa que dá a agentes acesso a telemetria, repositórios e capacidade de atuação, essa promoção é o aviso mais relevante do ano.
O padrão arquitetural a evitar é conhecido: um agente que reúne simultaneamente acesso a dado privado, exposição a conteúdo não confiável e capacidade de comunicação externa. Enquanto os três coexistirem no mesmo contexto, injeção indireta permanece explorável por desenho, e nenhum filtro de entrada resolve. As mitigações que sobrevivem à auditoria são de arquitetura, não de prompt: isolamento entre instrução e dado, ferramentas com esquema estreito e auditado em vez de acesso a linha de comando de nuvem, execução no contexto autenticado do usuário final, autorização verificada no sistema de destino e não decidida pelo modelo, e confirmação humana para ação de alto impacto.
Vale lembrar o caso que tornou isso concreto: um token de repositório com escopo inadequado permitiu inserir uma instrução maliciosa numa extensão de desenvolvimento com centenas de milhares de instalações, mandando o agente apagar arquivos locais e recursos de nuvem — usando exatamente as ferramentas que ele tinha permissão legítima de usar.
Esta é a Parte I de uma série de três do artigo “Da lacuna ao controle”. A Parte II — “Da lacuna ao controle – Parte II” — detalha qual classe de modelo roda em cada etapa, a especificação completa do harness (cinco agentes, harness.yaml, os dois portões que reprovam) e os seis prompts prontos que fecham cada lacuna.
Leia a Parte II Da lacuna ao controle – Parte II
