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

This paper introduces ESAA-Security, an event-sourced architecture that transforms AI-assisted security auditing from unreliable free-form LLM conversations into a traceable, reproducible, and verifiable governance pipeline by separating agent cognition from deterministic state mutations to ensure immutable audit trails for AI-generated code.

The Gist

Here is an explanation of the ESAA-Security paper, translated into everyday language with creative analogies.

The Big Problem: The "Magic" That Can't Be Trusted

Imagine you hire a super-smart, magical intern (an AI) to write code for your bank. It works incredibly fast. But here's the catch: the intern might accidentally leave the front door unlocked, hide a spare key under the mat, or forget to lock the vault.

In the past, when we asked AI to check its own work, we just said, "Hey, look for bugs!" The AI would chat back, "I found three things!" and write a paragraph about them.
The problem?

1. It's a black box: We don't know how it found them. Did it guess? Did it hallucinate?
2. It's messy: If you ask it again tomorrow, it might give you a different answer.
3. No proof: If the bank gets hacked, you can't prove the AI actually checked the door or just made it up.

The Solution: ESAA-Security (The "Flight Recorder" for Code)

The authors propose ESAA-Security. Think of this not as a chat with a smart intern, but as a strictly regulated construction site with a "Flight Recorder" (like on an airplane) that never deletes anything.

Here is how it works, broken down into simple concepts:

1. The "Black Box" vs. The "Event Log"

• Old Way: You ask the AI, "Is this code safe?" It thinks for a second and says, "Yes, mostly." You have to take its word for it.
• ESAA Way: The AI doesn't just "think." It has to write down every single step it takes in a permanent, unchangeable diary (called an Event Log).
  • Analogy: Imagine a detective solving a crime. In the old way, the detective just tells you the verdict. In ESAA, the detective must tape-record every clue they find, every door they open, and every fingerprint they lift. If the recording stops, the case is invalid.

2. The "Orchestrator" (The Strict Foreman)

In this system, the AI (the agent) isn't the boss. There is a Foreman (the Orchestrator).

• The AI wants to say, "I found a hole in the wall!"
• The Foreman stops it and says, "Hold on. Did you follow the rules? Did you check the right spot? Is your report in the correct format?"
• If the AI tries to skip steps or write a messy report, the Foreman rejects it. Nothing gets saved unless it passes the rules.

3. The "Replay" Feature (The Time Machine)

Because every step is recorded in that permanent diary, you can hit "Rewind" at any time.

• Analogy: Imagine a video game where you can replay a level. If the AI says, "I checked the password security," you can rewind the tape, watch the AI check the password, and verify it actually did the job correctly.
• This makes the audit reproducible. You aren't trusting the AI's memory; you are trusting the recorded evidence.

How the Audit Happens (The 4-Step Assembly Line)

Instead of a free-flowing conversation, ESAA-Security turns security checking into a factory assembly line with four distinct stations:

1. Reconnaissance (The Scout): The AI maps out the building. "Okay, we have a front door, a back window, and a server room."
2. Domain Audit (The Inspectors): Specialized teams check specific areas. One team checks the locks (Authentication), another checks the windows (Input Validation), another checks the wiring (Cryptography).
3. Risk Classification (The Graders): All the findings are sorted. "This is a critical hole (CRITICAL)," "This is a loose screw (LOW)." They create a "Risk Matrix" (a map of danger).
4. Final Reporting (The CEO Briefing): The system generates a final report. It's not just a chat; it's a structured document with a score (0–100), a list of fixes, and an executive summary.

Why This Matters (The "So What?")

The paper argues that in the age of AI-generated code, trust is the new currency.

• Before: We trusted the AI because it sounded confident.
• Now: We trust the process because the AI had to follow a strict contract, leave a paper trail, and pass a "replay" test.

If the AI makes a mistake, the system catches it. If the AI tries to cheat, the system rejects it. The final report isn't just an opinion; it's a verifiable fact built on a chain of evidence.

The Bottom Line

ESAA-Security is like turning a chaotic, unregulated chat with a genius into a courtroom trial.

• The AI is the witness.
• The "Event Log" is the court transcript.
• The "Orchestrator" is the judge.
• The "Replay" is the appeal process.

The result? A security audit you can actually trust, even when the work was done by a machine.

Technical Summary

Based on the paper "ESAA-Security: An Event-Sourced, Verifiable Architecture for Agent-Assisted Security Audits of AI-Generated Code," here is a detailed technical summary covering the problem, methodology, contributions, results, and significance.

1. Problem Statement

The rapid adoption of AI-assisted software generation (including "vibe coding") has accelerated development but introduced a critical governance gap in security auditing.

• The Core Issue: While Large Language Models (LLMs) can generate functionally correct code, they often produce systems that are structurally insecure (e.g., weak authentication, poor input validation, exposed secrets).
• Limitations of Current Approaches: Traditional prompt-based security reviews suffer from:
  • Uneven Coverage: Reliance on ad-hoc prompts leads to implicit scope and missed domains.
  • Weak Reproducibility: Findings are often unstructured narratives that cannot be replayed or verified.
  • Lack of Audit Trails: There is no immutable record of how conclusions were reached, making it difficult to distinguish between a valid finding and a model hallucination.
  • State Inconsistency: Agentic workflows operating over long horizons struggle with mutable state and context degradation, leading to unreliable intermediate steps.

2. Methodology: The ESAA-Security Architecture

The paper proposes ESAA-Security, a domain-specific specialization of the ESAA (Event-Sourced, Agent-Assisted) architecture. It shifts security auditing from a "free-form conversation" to a governed execution pipeline.

A. Architectural Principles

• Event Sourcing & CQRS: The system treats the append-only event log as the single source of truth, rather than mutable repository snapshots. Current state is reconstructed via deterministic projection and replay.
• Separation of Concerns:
  • Agents: Emit structured intentions under strict contracts. They do not directly mutate the system state.
  • Orchestrator: Validates agent intentions against contracts, persists accepted events, and manages state transitions.
• Fail-Closed Validation: Invalid transitions, schema violations, or boundary breaches are rejected before they affect the state, ensuring the event log remains authoritative.

B. The Execution Protocol

The audit is operationalized into a four-phase pipeline with strict invariants:

1. Reconnaissance: Identifies the tech stack, architecture, data flows, and attack surfaces.
2. Domain Audit Execution: Runs playbook-driven audits across 16 security domains.
3. Risk Classification: Consolidates findings into inventories, severity assignments, and risk matrices.
4. Final Reporting: Generates technical remediations, executive summaries, and final reports.

Key Invariants:

• Claim-Before-Work: Agents must claim a task before performing work.
• Complete-After-Work: Tasks are only completed with verification evidence and bounded file updates.
• Lock Ownership & Immutability: Ensures task ownership is clear and completed tasks cannot be silently reopened; corrections require explicit issue flows.

C. Scope and Coverage

The framework encodes security knowledge into 26 tasks across 16 security domains (including Secrets, AuthN/AuthZ, Input Validation, AI/LLM Security, and Supply Chain), totaling 95 executable checks. This replaces implicit model recall with explicit, encoded coverage.

3. Key Contributions

The paper makes four primary contributions:

1. Domain Specialization: It adapts the general ESAA governance kernel specifically for evidence-based security auditing of AI-generated or AI-modified code.
2. Governed Audit Pipeline: It defines a workflow combining constrained agent outputs, append-only event persistence, deterministic reprojection, and replay-based verification.
3. Operationalization: It structures the audit into a concrete hierarchy (4 phases, 26 tasks, 16 domains, 95 checks) that produces structured artifacts from check-level findings to final risk reports.
4. New Evaluation Framework: It proposes that the success of an AI security audit should be measured not just by the count of vulnerabilities found, but by traceability, reproducibility, coverage explicitness, artifact completeness, and remediation usefulness.

4. Results and Outputs

The system produces a hierarchical set of outputs that evolve from raw data to decision-making artifacts:

• Structured Evidence: Findings are not free-form text but structured objects binding check IDs, severity, code evidence, and remediation guidance.
• Vulnerability Inventory & Risk Matrix: Findings are aggregated and classified (CRITICAL to INFO) using CIA (Confidentiality, Integrity, Availability) reasoning.
• Remediation Guidance: Includes specific technical fixes and best-practice hardening guides.
• Final Report: A human-readable and structured JSON report that serves as the "terminal projection" of the event log, fully traceable back to the original checks.

Validation Plan: The paper outlines a validation strategy using case studies of varying complexity (including AI-generated repos) compared against baselines (prompt-only and checklist-only). Success is defined by protocol compliance, replay-verifiable state integrity, and the completeness of the artifact chain.

5. Significance and Implications

• Paradigm Shift: ESAA-Security argues that AI-assisted security review should be treated as a governed execution problem, not merely a prompting problem. The quality of the audit is defined by the integrity of the process, not just the persuasiveness of the model's prose.
• Trust & Accountability: By making the audit trail immutable and replayable, the framework allows organizations to trust the audit results even when generated by probabilistic AI models.
• AI-Specific Risks: It explicitly addresses risks unique to AI-generated code (e.g., prompt injection, dependency hygiene in AI contexts) which traditional AppSec frameworks often miss.
• Limitations: The authors acknowledge that the framework does not guarantee the absence of vulnerabilities (it is not a penetration test) and depends heavily on the quality of the underlying playbooks and the availability of repository context.

In conclusion, ESAA-Security provides a trace-first, verifiable architecture that transforms security auditing from an opaque, conversational activity into a transparent, reproducible, and auditable engineering process, specifically tailored for the challenges of AI-accelerated software development.