EZ Control kan rette skyavvik selv – men åpner først med lesetilgang

I env zeros kunngjøring fra DevOpsCon & AI Platform Engineering Day i New York 29. september 2026 åpnet selskapet tidlig tilgang til EZ Control, og toppsjef Steve Corndell sa: «Autonomy is only ever as trustworthy as the context underneath it.» Tjenesten skal finne avvik mellom ønsket og faktisk tilstand i skyinfrastruktur og kan rette dem automatisk når den får myndighet til det. Den første tilkoblingen er agentløs og gir bare lesetilgang, slik at ressurser og avvik kan kartlegges før tjenesten får endre noe.

En omtale i DevOps.com fra 29. september 2026 beskriver tidlig tilgang til en SaaS-tjeneste som omfatter nær 2300 ressurstyper i Kubernetes og skytjenester fra Amazon, Google og Microsoft. Team kan la EZ Control bare observere, foreslå retting, handle etter godkjenning eller handle autonomt innenfor fastsatte grenser. Tidlig tilgang er et program interesserte virksomheter kan melde seg til, ikke en generell utrulling med dokumenterte resultater fra kundemiljøer.

Fra oppdaget avvik til valgt retting

EZ Control skal samle informasjon om hva som faktisk kjører, og sammenholde den med infrastrukturkode og gjeldende regler. En ressurs kan avvike etter en manuell endring i skykonsollen, en hasteendring under en hendelse eller en automatisert utrulling utenfor den vanlige prosessen. Poenget med kartleggingen er å gi hvert funn en sammenheng før en retting velges: Hvilken kode opprettet ressursen, hvilket team eier den, hva er den avhengig av, og hvilke regler gjelder?

Dette bygger på kombinasjonen av env zeros styring av infrastruktur som kode og ressurskartleggingen fra CloudQuery. Tjenesten knytter også ressurser til kostnader og risiko, slik at et avvik fra kode kan behandles annerledes enn et brudd på en sikkerhets- eller kostnadsregel. Bredden i en ressursoversikt sier likevel ikke hvor mange typer avvik som kan rettes automatisk; en funnet ressurs må også ha riktig eier, regel og rettemetode.

Ved utilsiktet drift er den beskrevne rettingen å bruke infrastrukturkoden på nytt. En tilsiktet endring kan i stedet bli en pull request til repositoriet som eier ressursen, mens en feil i kildekoden merkes for korrigering. For brudd på regler om blant annet sikkerhet, kostnad, tilgjengelighet, vedlikehold og ytelse følger rettingen den aktuelle regelen. Etter en utført endring skal en ny skanning kontrollere om avviket er lukket.

Lesetilgang før større fullmakter

Startpunktet er observasjon uten installert agent og uten skriverettigheter. Deretter kan et plattformteam øke myndigheten for én ressursklasse om gangen. Det gjør det mulig å beholde én klasse under observasjon, kreve godkjenning for en annen og tillate automatisk retting av en tredje innenfor en definert policy. Grensen settes altså etter hvilke ressurser og handlinger teamet vil overlate til tjenesten, ikke bare ved å slå all automatisering av eller på.

Skillet betyr noe fordi samme synlige avvik kan ha ulike årsaker. Hvis en bevisst hasteendring behandles som utilsiktet drift, kan en automatisk gjenbruk av gammel kode fjerne endringen. Hvis en ressurs knyttes til feil repository eller feil eier, kan også en tilsynelatende rimelig pull request havne i feil gjennomgang. Koblingen mellom ressurs, kode og ansvar bør derfor stemme før tjenesten får fullmakt til å utføre den foreslåtte handlingen.

Handlingene beskrives som sporbare, reversible og reviderbare, også når KI-agenter inngår i arbeidsflyten. En ny skanning kan vise at et bestemt avvik er borte, men sier ikke alene om en endring kan omgjøres trygt hvis den påvirker avhengige ressurser. For en virksomhet i tidlig tilgang er dette en egenskap som må prøves i eget miljø, med den samme godkjenningsprosessen og de samme grensene som vil gjelde i drift.

Prøven før en ressursklasse får skrivetilgang

Overgangen fra observasjon til endringsmyndighet bør begynne med et avgrenset feilscenario. Et plattformteam kan bruke en testressurs der en tilsiktet endring skaper forskjell mellom kode og faktisk tilstand. Først bør det se om EZ Control finner ressursen og knytter den til riktig kode, eier og policy. Deretter bør teamet kontrollere om tjenesten foreslår å bruke koden på nytt, opprette en pull request eller melde en kodefeil, og om begrunnelsen passer med endringen som ble gjort. Dette er en foreslått kjøpertest, ikke et rapportert testresultat.

Før samme ressursklasse får skrivetilgang, bør prøven dekke tre forhold:

• Minste privilegium: Er tilgangen begrenset til de aktuelle kontoene, ressursene og handlingene, og gjelder en godkjenning akkurat den rettingen som ble vurdert?
• Reversering: Hva skjer hvis en retting stanser underveis, påvirker en avhengig ressurs eller må trekkes tilbake etter at kontrollskanningen er fullført?
• Revisjonsspor: Kan teamet følge funn, gjeldende regel, beslutning, eventuell godkjenning, utført handling og kontrollskanning som én etterprøvbar hendelse?

Særlig for autonome handlinger må sporet vise hvem eller hva som utløste endringen, hvilken fullmakt som gjaldt, og hvilken versjon av kode eller regel beslutningen bygde på. Hvis en av disse koblingene er feil eller mangler i et avgrenset forsøk, gir godkjenning før handling fortsatt teamet en kontrollmulighet. Erfaringene fra slike forsøk vil avgjøre hvilke ressursklasser virksomheter faktisk kan gi EZ Control myndighet til å endre.

Les også:

• Zapier eller Make: enkel oppstart kan bli den dyreste løsningen
• Asana eller monday.com: den enkleste starten kan bli dyr ved vekst
• DNB eller Nordnet: små aksjekjøp kan tape før kursen beveger seg