Hvorfor AI-drevne ændringer kræver bevis – ikke bare tilladelse

Før var det simpelt at ændre på infrastrukturen. En erfaren udvikler loggede ind på en server, skrev en kommando og krydsede fingre for, at dokumentationen stadig holdt. Den tid er forbi. Nu overlader vi komplekse opgaver som migreringer, kapacitetsjusteringer og sikkerhedsopdateringer til AI-agenter – og vi mangler en måde at kontrollere, at det faktisk er sikkert.

Den klassiske sikkerhedsmodel er ikke længere nok.

RBAC er ikke skabt til AI

De fleste produktionsmiljøer har stadig to lag af kontrol:

• RBAC styrer, hvem der må ændre på produktion.
• GitOps fortæller, hvordan systemet bør se ud.

Men ingen af dem svarer på det vigtigste spørgsmål: Hvorfor er denne ændring sikker lige nu?

Når en menneskelig operatør laver en ændring, har vedkommende erfaring og dømmekraft med sig. En AI-agent har ikke den samme kontekst. Den ved ikke, hvad der er vigtigt, eller hvad der kan gå galt. Den ved kun, at den har tilladelse.

Det bliver ekstra kritisk, når vi taler om ændringer, der ikke kan rulles tilbage – for eksempel en database-migrering eller en konfigurationsændring med mange afhængigheder.

Bevisbaseret ændringskontrol

Løsningen er at pakke hver foreslået ændring ind i et kryptografisk bevis, før den bliver udført. Det handler ikke bare om at godkende en kommando, men om at bevise, at den er sikker.

Processen ser sådan ud:

1. Agenten foreslår ændringen med begrundelse.
2. Systemet genererer et bevis for, at ændringen er sikker.
3. En politik kontrollerer, om ændringen er tilladt.
4. Beviset verificeres kryptografisk.
5. Ændringen udføres kun, hvis alt er i orden.
6. Hele forløbet gemmes med signatur og tidsstempel.

Beviset indeholder blandt andet tørkørsel mod det aktuelle miljø, sikkerhedsscanning, billede-digests, SLO-forudsigelser og kontrol af, om systemets tilstand matcher forventningerne.

Et konkret eksempel: Migrering fra Oracle til PostgreSQL

Forestil dig en reel migrering fra et Oracle/APEX-system til PostgreSQL i Kubernetes. Det er ikke bare en række YAML-filer – det er en lang række trin med data, rollback-muligheder og compliance-krav.

Når en AI-agent foreslår at køre denne migrering, genereres et bevis med:

• 23 valideringer på tværs af infrastruktur, skema og sikkerhed
• 20 hændelser, der dokumenterer hvert trin
• 20 signerede artefakter, der beviser, at hvert trin er udført korrekt
• En samlet score på 100 %, der viser, at alle gates er passeret

Beviset er signeret med en ed25519-nøgle og kan verificeres senere med kommandoen torque proof verify --require-signature.

Både bevis og politik er nødvendige

Selv når beviset er i orden, kræver systemet stadig eksplicit tilladelse. I test blev den samme anmodning afvist to gange:

• Første gang fordi operationen ikke var på tilladelseslisten.
• Anden gang fordi beviset var manipuleret – signaturen fejlede.

Det er forsvar i dybden: både bevis og politik skal være på plads.

Hvad det betyder for din infrastruktur

Værktøjer som Argo CD og Crossplane er stadig nyttige, men de er ikke designet til autonome agenter, der laver ændringer uden menneskelig indblanding. De kan fortælle, hvem der må ændre, og hvad der er målet – men ikke hvorfor en specifik ændring er sikker lige nu.

Hvis du arbejder med AI-assisterede deploymenter, autonome skaleringer eller komplekse migreringer på tværs af clouds, har du brug for en ny tilgang til ændringskontrol.

Hvad du kan gøre nu

Start med at sikre, at dit system kan:

• Generere kryptografiske beviser for, hvorfor en ændring er sikker.
• Definere eksplicitte tilladelsesregler for AI-agenter.
• Oprette signerede og genspilbare logfiler over alle ændringer.
• Give en score, der viser, hvor sikker en ændring er.

Infrastrukturen bevæger sig mod autonome operationer. Din ændringskontrol bør følge med – fra "har du lov?" til "her er beviset på, at det er sikkert".