ESAA-Security: An Event-Sourced, Verifiable Architecture for Agent-Assisted Security Audits of AI-Generated Code

O artigo apresenta o ESAA-Security, uma arquitetura de auditoria de segurança baseada em eventos e verificável que transforma a revisão de código gerado por IA de conversas livres em um processo governado, reprodutível e com rastro de auditoria imutável, estruturado em fases de reconhecimento, execução, classificação de riscos e relatórios.

O essencial

Imagine que você está construindo uma casa muito rápida, usando um ajudante de IA que escreve os planos e até assenta os tijolos em segundos. O problema é que, embora a casa pareça linda e funcione perfeitamente (as luzes acendem, a água corre), ela pode ter portas trancadas de forma errada, janelas quebradas ou um sistema elétrico que pega fogo se você ligar o ar-condicionado.

O papel que você leu, ESAA-Security, é como um novo tipo de inspetor de obras super rigoroso e organizado para essas casas construídas por IA.

Aqui está a explicação simples, usando analogias do dia a dia:

1. O Problema: A Conversa vs. O Processo

Antes, quando alguém queria verificar a segurança de um código feito por IA, era como se você pedisse a um amigo: "Ei, olhe essa casa e me diga se tem algo errado".

• O problema: O amigo pode esquecer de olhar o porão, pode ter um dia ruim e não ver o fio desencapado, ou pode dar uma resposta confusa como "acho que está tudo bem, mas não tenho certeza". Não há como provar depois o que ele viu ou não viu.

O ESAA-Security muda isso. Em vez de uma conversa livre, ele transforma a inspeção em uma linha de montagem de fábrica. Nada é deixado ao acaso.

2. A Solução: O "Livro de Atas" Imutável

A ideia central do ESAA é usar um Livro de Atas (Event Sourcing).

• A Analogia: Imagine um livro de atas de uma reunião onde é proibido rasurar ou apagar qualquer coisa. Se alguém diz algo, é escrito. Se alguém toma uma decisão, é registrado.
• Como funciona na prática: O agente de IA (o inspetor) não pode simplesmente "mudar" o código ou dizer que achou um erro. Ele precisa:
  1. Pedir permissão: "Vou inspecionar a porta da frente".
  2. Fazer o trabalho: Inspeciona e escreve o resultado.
  3. Registrar: O resultado é escrito no "Livro de Atas" de forma permanente.
  4. Verificar: Um "chefe" (o Orquestrador) lê o livro e confirma se a inspeção foi feita corretamente antes de permitir a próxima etapa.

Se o inspetor tentar pular etapas ou inventar um erro, o sistema bloqueia. Isso cria um rastro de papel digital que nunca pode ser apagado.

3. O Processo em 4 Etapas (A Jornada do Inspecto)

O sistema divide a inspeção em quatro fases claras, como se fosse um roteiro de filme:

1. Reconhecimento (O Mapa): Antes de tocar em nada, o sistema desenha um mapa da casa. "Quais são as janelas? Onde estão as portas? Qual é o sistema elétrico?".
2. Execução (A Varredura): O inspetor vai quarto por quarto (cada área de segurança) seguindo um checklist rígido. Não é "olhe e veja o que acha", é "verifique se a fechadura da porta 1 está funcionando". São 95 verificações específicas!
3. Classificação de Risco (A Triagem): Se algo for encontrado, o sistema não grita "PERIGO!". Ele classifica: "Isso é um risco crítico (a casa pode pegar fogo)", "Médio (a porta range)" ou "Baixo (a tinta está descascando)".
4. Relatório Final (O Laudo): No final, você não recebe apenas uma conversa. Você recebe um Laudo Oficial com:
   • O que foi encontrado.
   • O quão grave é.
   • Como consertar (o "manual de reparo").
   • Um resumo para o dono da casa (o executivo) entender o risco sem precisar ler 100 páginas de detalhes técnicos.

4. Por que isso é revolucionário?

A grande sacada do ESAA-Security é que ele não confia na "opinião" da IA, mas sim no "processo".

• Antes: A IA dizia "Acho que há um buraco na cerca". Você tinha que confiar nela.
• Agora: O sistema diz: "A IA seguiu o passo 1, depois o passo 2, tirou uma foto do buraco, registrou no livro de atas e o chefe validou. Aqui está a prova do buraco e o plano para tapá-lo".

Se alguém quiser auditar o trabalho no futuro, basta "reproduzir" (replay) o que foi registrado no Livro de Atas. Se o processo foi seguido, o resultado é confiável.

Resumo em uma frase

O ESAA-Security transforma a segurança de códigos feitos por IA de uma conversa informal e esquecível em um processo industrial auditável, passo a passo e impossível de falsificar, garantindo que, mesmo com a velocidade da IA, a segurança seja sólida e verificável.

Resumo técnico

Resumo Técnico: ESAA-Security

1. O Problema

O desenvolvimento de software assistido por Inteligência Artificial (IA) acelerou a criação de código, mas exacerbou um problema de engenharia persistente: sistemas podem ser funcionalmente corretos, mas estruturalmente inseguros.

• Limitações das Revisões Atuais: As revisões de segurança baseadas em prompts com Grandes Modelos de Linguagem (LLMs) sofrem de cobertura desigual, fraca reprodutibilidade, achados não suportados por evidências e a ausência de um rastro de auditoria imutável.
• Risco de Governança: Em fluxos de trabalho agênicos (onde agentes de IA executam tarefas complexas), o estado mutável, o contexto incompleto e os passos intermediários não verificáveis tornam-se riscos operacionais críticos.
• Falha na Abordagem Tradicional: A revisão de segurança não deve ser modelada como uma conversa livre com um LLM, mas sim como um processo de auditoria orientado a evidências. O problema não é apenas se o modelo encontra vulnerabilidades, mas se a avaliação resultante é explícita, estruturada, reprodutível e rastreável.

2. Metodologia e Arquitetura (ESAA-Security)

O artigo propõe o ESAA-Security, uma especialização de domínio da arquitetura ESAA (Event-Sourced Agent-Assisted), focada na auditoria de repositórios de software, especialmente aqueles gerados ou modificados por IA.

Princípios Fundamentais:

• Event Sourcing (Origem de Eventos): O registro de eventos (append-only log) é a "fonte da verdade", não o snapshot do repositório. O estado atual do projeto é reconstruído deterministicamente através da projeção e replay desses eventos.
• Separação de Cognição e Mutação: Os agentes emitem "intenções estruturadas" sob protocolos restritos. Um orquestrador valida essas intenções contra contratos antes de persistir qualquer alteração no estado.
• Verificação por Replay: A consistência é verificada através de replay e hashing, garantindo que o estado auditado seja reprodutível.

O Pipeline de Execução Governada:
A auditoria é estruturada em um pipeline de quatro fases, operando sobre 26 tarefas, 16 domínios de segurança e 95 verificações executáveis:

1. Reconhecimento: Identificação da pilha tecnológica, arquitetura, fluxos de dados e superfícies de ataque.
2. Execução da Auditoria de Domínio: Execução de auditorias guiadas por "playbooks" (roteiros) sobre o repositório, uma tarefa por domínio de segurança.
3. Classificação de Risco: Consolidação dos achados em inventários de vulnerabilidades, atribuição de severidade e matrizes de risco.
4. Relatório Final: Geração de orientações de remediação técnica, resumos executivos e relatórios finais estruturados (Markdown/JSON).

Invariantes de Execução:
O protocolo garante a integridade através de regras rígidas, como:

• Claim-before-work: Uma tarefa deve ser "reivindicada" antes que o trabalho seja iniciado.
• Complete-after-work: A conclusão só ocorre após a emissão de evidências de verificação.
• Imutabilidade: Uma vez concluída, uma tarefa não pode ser reaberta silenciosamente; correções devem seguir fluxos explícitos.
• Validação Fail-Closed: Transições inválidas ou violações de esquema são rejeitadas antes de afetarem o estado.

3. Principais Contribuições

O artigo apresenta quatro contribuições principais:

1. Especialização Arquitetural: Adaptação do kernel de governança ESAA para auditoria de segurança baseada em evidências, focada em software assistido por IA.
2. Pipeline Governado: Definição de um fluxo de trabalho que combina saídas estruturadas de agentes, persistência de eventos de apenas adição (append-only), reprojeção determinística e verificação baseada em replay.
3. Operacionalização da Segurança: Transformação da revisão de segurança em um processo estruturado com 4 fases, 26 tarefas e 95 verificações cobrindo domínios como autenticação, injeção, criptografia, segurança de IA/LLM e DevSecOps.
4. Novo Modelo de Avaliação: Proposta de que o sucesso da auditoria não deve ser medido apenas pela enumeração de vulnerabilidades, mas pela rastreabilidade, reprodutibilidade, explicitação da cobertura, completude de artefatos e utilidade da remediação.

4. Resultados e Saídas

O framework produz uma cadeia de artefatos hierárquica e estruturada:

• Achados de Nível de Verificação: Objetos de evidência estruturados (não narrativas livres) contendo identificador, status, severidade, evidência de código/configuração e orientação técnica.
• Inventário de Vulnerabilidades: Transformação de achados locais em estado de segurança do sistema.
• Classificação e Matriz de Risco: Uso de categorias (CRÍTICO, ALTO, MÉDIO, BAIXO, INFO) e raciocínio baseado em CIA (Confidencialidade, Integridade, Disponibilidade) para priorizar ações.
• Relatório Final: Um documento que não é uma narrativa gerada do zero, mas a projeção terminal de uma sequência de transições de estado admitidas. Inclui um escore de segurança (0-100) e resumo executivo.

5. Significado e Conclusão

O ESAA-Security representa uma mudança conceitual fundamental na auditoria de segurança assistida por IA:

• Mudança de Paradigma: A qualidade da auditoria deixa de ser julgada pela "persuasão" do texto gerado pelo modelo e passa a ser julgada pela capacidade de reconstruir, verificar e confiar no processo governado.
• Auditoria por Construção: O relatório final é auditável por construção, pois deriva diretamente de um rastro de eventos imutável e verificável.
• Limitações e Futuro: O framework não substitui testes de penetração nem garante a ausência total de vulnerabilidades. Sua força reside na maturidade de auditoria interna e na rastreabilidade. Trabalhos futuros visam integrar CVSS, DAST híbrido e auditoria de múltiplos repositórios.

Em suma, o ESAA-Security oferece uma arquitetura técnica para transformar a revisão de segurança de uma atividade de "prompting" ad hoc em um processo de engenharia de software rigoroso, auditável e reprodutível, essencial para a era do software gerado por IA.