Hvorfor AI-drevne endringer i infrastrukturen krever bevis – ikke bare tillatelse

Før var det enkelt å endre ting i produksjon. En erfaren utvikler logget inn på en server, kjørte en kommando og håpet at alt gikk bra. Nå er det AI-agenter som tar seg av komplekse oppgaver som migreringer, skalering og sikkerhetsoppdateringer. Da holder det ikke lenger å bare sjekke om noen har tilgang.

Tradisjonelle tilgangskontroller er ikke laget for denne typen operasjoner.

RBAC holder ikke mål når AI tar over

De fleste miljøer bruker fortsatt RBAC og GitOps for å styre hva som får lov til å skje. RBAC sier hvem som kan gjøre hva. GitOps beskriver hvordan systemet skal se ut. Men ingen av delene svarer på det viktigste spørsmålet: Hvorfor er akkurat denne endringen trygg akkurat nå?

Når en AI-agent foreslår en database-migrering eller en stor infrastrukturendring, mangler vi den menneskelige vurderingen. Vi sjekker bare tillatelser, ikke begrunnelsen bak endringen. Det blir ekstra risikabelt når vi snakker om operasjoner som ikke kan rulles tilbake.

Bevisbasert endringskontroll

Løsningen er å la hver foreslåtte endring bli ledsaget av kryptografiske bevis før den kjøres. Tenk på det som en digital signatur for infrastrukturendringer.

Arbeidsflyten er enkel:

1. Agenten foreslår en endring med full begrunnelse
2. Systemet genererer bevis for at endringen er trygg
3. Policy-motoren sjekker om endringen er tillatt
4. Bevisene verifiseres kryptografisk
5. Endringen kjøres bare hvis alt er godkjent
6. Alt logges med full historikk

Bevisene inkluderer tørrkjøring mot reell infrastruktur, sjekk for avvik, sikkerhetsskanning, bildehasher og prediksjoner om hvordan endringen påvirker SLA-er.

Et virkelig eksempel: Migrering fra Oracle til PostgreSQL

En konkret migrering fra Oracle/APEX til PostgreSQL i Kubernetes krever over tjue steg. Det handler om alt fra klargjøring av clusteret og frysing av kildedata til validering etter cutover. Dette er ikke noe du bare «kjører».

Når en AI-agent ber om å kjøre en slik sekvens, genereres det bevis som dekker 23 valideringspunkter, 20 hendelser underveis og 20 uavhengige bekreftelser. Alt signeres med en ed25519-nøkkel og kan verifiseres i ettertid.

Både bevis og policy må godkjennes

Selv med bevis på plass, kreves det fortsatt eksplisitt godkjenning. I tester ble samme forespørsel avslått to ganger – først fordi operasjonen ikke var på tillatelseslisten, deretter fordi bevisene var tuklet med. Dette gir to lag med beskyttelse.

Hvorfor dette blir viktig fremover

Verktøy som Argo CD og Crossplane er bygget for en tid før autonome agenter ble vanlig. De kan fortelle deg hvem som har tilgang og hva ønsket tilstand er, men ikke hvorfor en bestemt endring er trygg.

Når du begynner å bruke AI til skalering, feilretting og komplekse migreringer, trenger du en infrastruktur som kan dokumentere og bevise hver endring.

Hva du bør tenke på

Start med å vurdere om deployment-systemet ditt kan generere kryptografiske bevis. Legg til policy som kode, sørg for at alle endringer logges med signatur, og mål hvor trygg en endring faktisk er før den kjøres.

Når AI-agenter skal håndtere produksjonsendringer midt på natta, er det bevisene som avgjør om du kan sove godt.