Waarom AI-gedreven infrastructuur bewijs nodig heeft, geen toestemming alleen

Vroeger was een infrastructuurwijziging overzichtelijk. Een senior engineer logde in op een server en voerde een commando uit. Vandaag laten we AI-agents steeds complexere taken uitvoeren: migraties, capaciteitsaanpassingen en security-patches. Maar hoe weet je zeker dat zo’n operatie veilig is?

Traditionele toegangscontrole schiet tekort.

RBAC is niet genoeg in een AI-omgeving

De meeste productieomgevingen vertrouwen nog op twee mechanismen:

• RBAC bepaalt wie toegang heeft tot productie.
• GitOps beschrijft de gewenste staat.

Geen van beide geeft antwoord op de vraag: waarom is deze specifieke wijziging op dit moment veilig?

Een menselijke operator gebruikt ervaring en context. Een AI-agent doet dat niet. Bij stateful operaties zoals database-migraties of grootschalige configuratiewijzigingen mist het systeem elk inzicht in afhankelijkheden en rollback-scenario’s.

Hoe ziet evidence-based change control eruit?

Een betere aanpak vereist cryptografisch bewijs voordat een mutatie wordt uitgevoerd. Het proces ziet er als volgt uit:

1. De agent stelt de wijziging voor, inclusief motivatie.
2. Het systeem genereert een cryptografisch bewijs.
3. Een policy-engine controleert of de wijziging voldoet aan de regels.
4. Het bewijs wordt geverifieerd op integriteit.
5. Pas daarna wordt de mutatie uitgevoerd.
6. Alles wordt vastgelegd in een replaybare audit trail.

Dit bewijs bevat onder meer:

• Dry-run resultaten tegen de actuele infrastructuur
• Drift-detectie
• Security-scans en SBOM
• Image-digests en build-provenance
• SLO-impactvoorspellingen
• Controle op de integriteit van de gebeurtenisketen

Voorbeeld: Oracle naar PostgreSQL migreren

Stel je een echte migratie voor: een Oracle/APEX-systeem verhuist naar PostgreSQL in Kubernetes. Het gaat om live data en een strikt change window. De stappen omvatten onder meer:

• Controleren of het Kubernetes-cluster klaar is
• Change-window goedkeuringen vastleggen
• De bronsystemen bevriezen
• Data exporteren en restore points aanmaken
• Schema-uitbreiding en shadow-tabellen
• Regel-voor-regel verificatie
• Cutover en validatie achteraf

Wanneer een AI-agent deze reeks aanvraagt, levert het bewijs 23 validatiechecks, 20 vlucht-events en 20 afzonderlijke bewijsstukken op. De volledige release scoort 100 %. Het bewijs is ondertekend met een ed25519-sleutel en later te controleren via torque proof verify --require-signature.

Dubbele beveiliging: bewijs én beleid

Zelfs met een geldig bewijs blijft expliciete autorisatie verplicht. In tests werd dezelfde aanvraag twee keer geweigerd:

• Eén keer omdat de operatie niet op de allow-list stond.
• Eén keer omdat het bewijs was gemanipuleerd en de handtekening faalde.

Alleen de combinatie van bewijs en beleid biedt echte bescherming.

Wat betekent dit voor jouw infrastructuur?

Tools als Argo CD en Crossplane zijn ontworpen vóór de opkomst van autonome agents. Ze kunnen aangeven wie mag schrijven en wat de gewenste staat is, maar niet waarom een bepaalde wijziging veilig is.

Naarmate je overstapt op:

• AI-gestuurde deployments
• Autonome scaling en herstel
• Multi-cloud migraties
• Sterk gereguleerde workloads

…heb je infrastructuur nodig die elke productie-mutatie cryptografisch kan onderbouwen.

Praktische eerste stappen

Begin met vier zaken:

1. Zorg dat je deployment-systeem cryptografisch bewijs kan genereren.
2. Leg expliciete allow-lists vast als policy-as-code.
3. Bouw replaybare, ondertekende audit trails.
4. Meet de betrouwbaarheid van elke wijziging met een gate-score.

De wereld van infrastructuur beweegt richting autonome operatie. Je change control moet meebewegen – van “heb je toestemming?” naar “hier is het bewijs dat het veilig is, en hier is waarom.”