Sikkerhetsforsker Yanir Tsarimi hos Enclave AI dokumenterte at Microsofts Azure SRE Agent hadde en autentiseringssvikt som eksponerte live agent-aktivitet til uautoriserte på nettet. CSO Online skriver at hullet er sporet som CVE-2026-32173 og klassifisert som kritisk med CVSS 8.6. Microsoft fikset feilen server-side, og tjenesten nådde general availability 10. mars.
Den tekniske mekanismen er skremmende enkel. Agenten streamet all aktivitet gjennom en WebSocket-endepunkt kalt /agentHub. Endepunktet krevde en token, men den underliggende Entra ID app-registreringen var konfigurert som multi-tenant. Det betyr at en konto fra en helt urelatert tenant kunne hente en gyldig token som hubben godtok. Hubben sjekket om tokenet var gyldig og om audience stemte, men aldri om den som ringte faktisk tilhørte målets tenant.
«Forestill deg at du ansetter en assistent som har tilgang til alt: servere, logger, passord, kildekode. Forestill deg så at en fremmed fra et helt urelatert selskap kunne lytte stille til hver samtale den assistenten har.» — Yanir Tsarimi, sikkerhetsforsker hos Enclave AI
Når du først var koblet til, broadcastet hubben alle hendelser til alle klienter uten identitetsfiltrering. Den eksponerte kanalen inkluderte brukerprompter, agent-svar, interne resonnementsspor, hver kommando som ble kjørt med fulle argumenter, og kommandoutdataene. I Enclaves eget testmiljø observerte de agenten kjøre en rutineoppgave og returnere deploy-credentials til live webapplikasjoner.
Exploitering krevde kun målets agent-subdomene — som Enclave beskrev som forutsigbar og enumerrbar — og omtrent 15 linjer Python.
«Et normalt API-problem er vanligvis bundet av et spesifikt endepunkt eller permission-sjekk. Med en KI-operasjonsagent blir agenten selv samlepunktet for infrastruktur-state, logger, kildekode, incident-kontekst, kommandoer, output og noen ganger credentials som dukker opp under feilsøking. I praksis kan det se ut som å se en privilegert operatør tenke høyt.» — Alexander Hagenah, sikkerhetsforsker og executive director ved SIX Group
Forbindelsen etterlot ingen spor hos offeret. Offerorganisasjoner hadde ingen måte å oppdage, etterforske eller ringe inn hva som var eksponert.
Hva bør du gjøre?
- Behandle preview-perioden som eksponert: Hvis teamet ditt kjørte Azure SRE Agent før fiksen, gå gjennom alle credentials, konfigurasjonsdata og sensitiv informasjon som kan ha passert gjennom agent-samtaler eller CLI-output. Roter dem.
- Krev resource-level auth for agentplattformer: Det er ikke nok at et token er gyldig. Tjenesten må verifisere at kalleren hører hjemme i riktig tenant, er autorisert for akkurat den agenten, og har tilgang til den spesifikke strømmen eller tool-outputen.
- Gi agenten minimum-tilganger: Kjør agenten under en dedikert managed identity og gjennomgå integrasjoner mot kommandokjøring, logg-spørringer, kildekoderepos og incident-plattformer som ethvert annet privilegert system.
Bakgrunn
Dette er nok en i rekken av multi-tenant-feil i KI-agenter som får bred infrastruktur-tilgang. Mønsteret er konsistent: agenten er designet for å se alt den trenger å feilsøke med, og det gjør den til en attraktiv lyttepost hvis auth-laget svikter. For nordiske virksomheter som kjører Azure som primær sky, er dette en påminnelse om å styre agent-tilgang like strengt som du styrer service principals med produksjonsrettigheter.