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

Dit paper introduceert ESAA-Security, een verifieerbare architectuur die agent-gestuurde beveiligingsaudits van AI-genereren code transformeert van vrije conversaties naar een traceerbaar, herhaalbaar proces dat gebaseerd is op append-only gebeurtenissen en replay-verificatie om een onbetwistbaar auditspoor te waarborgen.

De kern

Hier is een uitleg van het paper over ESAA-Security, vertaald naar eenvoudige, alledaagse taal met creatieve analogieën.

🛡️ De Grote Uitdaging: Sneller bouwen, maar minder veilig

Stel je voor dat je een gigantisch huis bouwt met een team van super-snelle, slimme robots (de AI). Deze robots kunnen in een paar minuten muren optrekken en ramen plaatsen waar een mens dagen over zou doen. Dat is geweldig voor de snelheid.

Maar er zit een addertje onder het gras: soms bouwen deze robots een muur die er perfect uitziet, maar waar een dief zo doorheen kan lopen omdat ze geen slot hebben geplaatst. Of ze vergeten de brandblusapparatuur te installeren.

Tot nu toe was het controleren van deze robots een beetje zoals een gesprek voeren met een vriend: "Kijk eens naar dit huis, zie je iets raars?" De robot (of de AI) geeft dan een antwoord. Het probleem is dat dit antwoord vaak willekeurig is. Soms vergeet de robot iets, soms is het antwoord niet te controleren, en als je het de volgende dag opnieuw vraagt, krijg je misschien een heel ander antwoord. Er is geen vast bewijs van wat er is gecontroleerd.

🏗️ De Oplossing: ESAA-Security (De "Onuitwisbare Bouwplaat")

Het paper introduceert ESAA-Security. In plaats van de AI te vragen om gewoon "te kijken", bouwen ze een streng, gestructureerd proces.

Stel je voor dat je niet gewoon vraagt: "Is dit huis veilig?", maar dat je de AI dwingt om te werken volgens een onuitwisbaar dagboek (een event log).

Hier is hoe het werkt, stap voor stap, met een analogie:

1. Geen vrijblijvend gesprek, maar een strikte procedure

In het oude model was de AI een vrijblijvende adviseur. In het nieuwe model (ESAA) is de AI een ambtenaar die werkt volgens een streng reglement.

• De Analogie: Stel je voor dat de AI een bouwvakker is die een onuitwisbare stempel moet zetten op elke stap die hij zet. Hij kan niet zomaar zeggen: "Ik denk dat de deur veilig is." Hij moet eerst een formulier invullen, een stempel zetten, en die stempel wordt direct in een glazen kast (het onuitwisbare dagboek) geplaatst. Niemand kan die stempel later wegpoetsen of veranderen.

2. De Vier Fasen van de Inspectie

Het proces is opgedeeld in vier duidelijke hoofdstukken, net als een detectiveverhaal:

1. Verkenning (Reconnaissance): De AI kijkt eerst naar het hele huis. Welke materialen zijn gebruikt? Waar lopen de elektriciteitskabels? Waar zitten de ingangen?
2. De Controle (Domain Audit): De AI gaat nu specifiek kijken naar 16 verschillende soorten risico's (zoals sloten, brandblussers, of of er geen geheime sleutels onder de mat liggen). Er zijn 95 specifieke checks die één voor één moeten worden gedaan.
3. De Risico-indeling (Risk Classification): Alle gevonden problemen worden niet zomaar opgeschreven. Ze worden ingedeeld: "Dit is een klein krassenprobleem (Laag risico)" of "Dit is een gat in de muur waar een auto doorheen kan (Kritiek risico)."
4. Het Eindrapport (Final Reporting): Uiteindelijk krijg je niet alleen een lijstje met fouten, maar een volledig dossier. Dit bevat een samenvatting voor de baas, een technische handleiding voor de reparatie, en een cijfer voor de veiligheid.

3. De "Regisseur" en de "Speler"

Dit is het slimme deel van de architectuur.

• De AI (De Speler): De AI doet het werk, maar hij mag niets direct veranderen in het systeem. Hij mag alleen voorstellen doen.
• De Regisseur (De Orchestrator): Dit is een strenge controleur. Hij kijkt naar het voorstel van de AI.
  • "Mag de AI dit formulier invullen?" -> Nee, want hij heeft nog geen toestemming.
  • "Is het formulier correct ingevuld?" -> Ja.
  • Dan pas wordt het formulier in het onuitwisbare dagboek geplakt.

Dit zorgt ervoor dat de AI niet zomaar kan liegen of hallucineren. Als hij iets zegt, moet het bewijs in het dagboek staan.

4. Waarom is dit zo belangrijk? (De "Herhaalbaarheid")

Stel je voor dat je over een jaar terugkijkt en vraagt: "Waarom dachten jullie dat dit huis veilig was?"

• Oude manier: De AI zegt: "Nou, ik herinner me dat ik het een keer gecontroleerd heb en het leek oké." (Dit is niet betrouwbaar).
• ESAA-methode: Je pakt het dagboek en je kunt precies zien: "Op dinsdag om 14:00 uur heeft de AI formulier 42 ingevuld, de Regisseur heeft het goedgekeurd, en hier is het bewijs."
  Je kunt het hele proces opnieuw spelen (replay) om te zien of het resultaat hetzelfde blijft. Als je het proces opnieuw start, krijg je exact hetzelfde resultaat. Dat noemen ze verifieerbaar.

🎯 Wat is het grote voordeel?

Het paper zegt eigenlijk: "Veiligheid controleren is niet een gesprek met een vriend, het is een juridisch proces."

• Geen willekeur: De AI kan niet zomaar iets overslaan omdat hij het even vergeten is. Hij moet alle 95 checks doen.
• Geen twijfel: Elk gevonden probleem heeft een bewijsstuk (een stukje code of een configuratie) dat direct gekoppeld is aan het rapport.
• Betrouwbaarheid: Omdat alles in het onuitwisbare dagboek staat, kun je het rapport gebruiken als bewijs in een rechtbank of voor een verzekeraar.

Conclusie in één zin

ESAA-Security verandert AI-veiligheidscontroles van een "gokje" in een strak, bewijsbaar en onuitwisbaar proces, waarbij elke stap van de AI wordt vastgelegd, gecontroleerd en herhaalbaar is, zodat we kunnen vertrouwen op de veiligheid van software die door AI is gemaakt.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het artikel "ESAA-Security: An Event-Sourced, Verifiable Architecture for Agent-Assisted Security Audits of AI-Generated Code" in het Nederlands.

Probleemstelling

De opkomst van AI-gestuurde softwaregeneratie heeft de ontwikkelingsnelheid aanzienlijk verhoogd, maar heeft ook een hardnekkig engineeringprobleem versterkt: systemen kunnen functioneel correct zijn, maar structureel onveilig. In de praktijk lijden prompt-gebaseerde beveiligingsreviews door grote taalmodellen (LLMs) aan verschillende tekortkomingen:

• Onvolledige dekking: De review is vaak willekeurig en niet gestructureerd.
• Gebrek aan reproduceerbaarheid: Het is moeilijk om te verifiëren hoe een bevinding tot stand is gekomen.
• Onondersteunde bevindingen: Bevindingen zijn vaak losse teksten zonder bewijslast.
• Afwezigheid van een onwrikbaar auditpad: Er is geen onveranderlijke log van de uitgevoerde acties.
  Bovendien lopen autonome agenten die over lange tijdshorizons werken het risico dat hun context incompleet wordt of dat tussenstappen niet verifieerbaar zijn, wat leidt tot operationele risico's in plaats van slechts prompt-irritaties.

Methodologie: ESAA-Security Architectuur

Het artikel introduceert ESAA-Security, een domeinspecifieke specialisatie van de ESAA-architectuur (Event-Sourced, Agent-Assisted). De kernfilosofie is dat beveiligingsreview niet gemodelleerd moet worden als een vrije conversatie met een LLM, maar als een gecontroleerd uitvoeringsproces dat gebaseerd is op contracten en gebeurtenissen.

De architectuur bestaat uit de volgende pijlers:

1. Event Sourcing & CQRS: De "waarheid" is niet de huidige staat van de repository, maar een append-only event log. De huidige staat wordt deterministisch gereconstrueerd (projectie) vanuit deze log. Dit zorgt voor een onveranderlijk auditpad.
2. Gestuurde Agenten: Agenten mogen de systeemstatus niet direct wijzigen. Ze zenden gestructureerde intenties uit onder strikte contracten. Een orkestrator valideert deze intenties voordat ze worden vastgelegd in de event log.
3. Verificatie door Replay: De consistentie wordt geverifieerd door de gebeurtenissen opnieuw af te spelen (replay) en te hashen.
4. Uitvoeringsprotocol: Het proces volgt een strikte "claim-before-work" en "complete-after-work" discipline. Taken moeten eerst worden opgeëist, waarna werk wordt uitgevoerd en alleen na verificatie worden afgerond. Dit voorkomt dat agents in een verouderde context werken.

De Audit Workflow:
Het proces is opgedeeld in vier fasen, 26 taken, 16 beveiligingsdomeinen en 95 uitvoerbare checks:

1. Reconnaissance: Identificatie van de technologie-stack, architectuur, dataflows en aanvalsoppervlakken.
2. Domein Audit Uitvoering: Het uitvoeren van playbook-gedreven audits per beveiligingsdomein (o.a. authenticatie, autorisatie, invoervalidatie, AI/LLM-risico's).
3. Risicoclassificatie: Consolidatie van bevindingen in kwetsbaarheidsinventarisaties, toewijzing van ernstniveaus (CRITICAL tot INFO) en het genereren van risicomatrices.
4. Rapportage: Generatie van technische remediëring, best practices, een samenvatting voor het management en een definitief auditrapport (in Markdown/JSON).

Belangrijkste Bijdragen

1. Architecturale Specialisatie: ESAA-Security vertaalt het algemene governance-kernel van ESAA naar de specifieke context van beveiligingsaudits voor AI-genererde code.
2. Gestructureerde Uitvoer: In plaats van vrije tekst, worden bevindingen geproduceerd als gestructureerde bewijsobjecten (check-ID, status, ernst, codebewijs, remediatie).
3. Operationalisatie: Het framework maakt beveiligingsreview operationeel via een vast protocol (4 fasen, 26 taken, 16 domeinen), wat zorgt voor expliciete dekking in plaats van impliciete recall door het model.
4. Nieuwe Evaluatiekader: De kwaliteit van een audit wordt niet alleen gemeten aan het aantal gevonden kwetsbaarheden, maar aan traceerbaarheid, reproduceerbaarheid, expliciete dekking, volledigheid van artefacten en bruikbaarheid van remediëring.

Resultaten en Validatie

Hoewel het artikel voornamelijk een architecturaal voorstel is, worden de verwachte resultaten en validatiestrategieën beschreven:

• Traceerbaarheid: Elke bevinding in het eindrapport is terug te leiden tot een specifieke, gevalideerde gebeurtenis in de log.
• Reproduceerbaarheid: Door de deterministische projectie van de event log kan elke audit exact worden gereproduceerd.
• Validatieplan: Het plan omvat case studies van verschillende complexiteit (kleine en middelgrote repositories, inclusief AI-genererde code).
• Benchmarks: De prestaties worden vergeleken met:
  • Prompt-only review: Waarbij een LLM vrij tekstueel reviewt.
  • Checklist-only review: Waarbij domeinen worden gevolgd zonder de ESAA-governance-laag.
  • Het doel is niet per se om meer kwetsbaarheden te vinden, maar om betere, auditbare en actievere outputs te leveren.

Betekenis en Impact

De belangrijkste betekenis van dit werk is een verschuiving in het paradigma van AI-beveiliging:

• Van "Prompten" naar "Governance": Beveiligingsreview wordt behandeld als een beheerd uitvoeringsprobleem, niet als een prompt-engineering uitdaging.
• Vertrouwen door Architectuur: Het vertrouwen verschuift van de "overtuigende tekst" van een model naar een "protocol-valid, replay-verifieerbaar" auditstaat.
• Toepasbaarheid op AI-Code: Het lost specifiek het probleem op van "vibe coding" (snelle, AI-gestuurde ontwikkeling) waarbij snelheid vaak ten koste gaat van beveiligingshygiëne en traceerbaarheid.

Beperkingen:
Het framework garandeert niet de afwezigheid van kwetsbaarheden en vervangt geen penetratietesten. De kwaliteit hangt af van de kwaliteit van de playbooks en de beschikbaarheid van context (bijv. infrastructuurdetails). Het is primair een methode voor interne audit-maturiteit, niet voor externe certificering.

Conclusie:
ESAA-Security biedt een robuust, bewijsgericht raamwerk om beveiligingsaudits in een AI-versneld ontwikkelomgeving uit te voeren. Het transformeert de audit van een subjectief gesprek naar een objectief, reproduceerbaar en juridisch onderbouwbaar proces.