AWS AgentCore-hull kunne kapre AI-agenter dette må du sjekke

Én agent som inngang til flere

En kjede av sikkerhetsproblemer i Amazon Bedrock AgentCore kunne gjøre én offentlig tilgjengelig agent til inngangspunkt for andre agenter i samme AWS-konto og region. Det viser Zenity Labs i en rapport publisert 8. oktober 2026. Funnene har fått navnet AgentCorruption.

Forskerne beskriver et kontrollert testoppsett der en agent fikk tilgang til midlertidige skylegitimasjoner fra miljøet den kjørte i. Med den tilhørende kjørerollen kunne de oppdage og kalle andre AgentCore-agenter, lese private samtaler og hente kildekode. I rapporten beskriver Zenity også tilgang til hemmeligheter og muligheten til å påvirke agentenes videre oppførsel. Dette er ikke dokumentasjon på at en bestemt norsk virksomhet er angrepet, men et varsel om hvordan agentinfrastruktur kan feile når tilgangene blir for brede.

Problemet lå i kombinasjonen

AgentCore-agenter trenger tilgang til ressurser for å være nyttige. De kan hente data, bruke API-er og utføre handlinger på vegne av en bruker eller en organisasjon. I Zenitys test ble denne nytten koblet til en kjørerolle med mer rekkevidde enn den enkelte agent burde ha hatt. Zenity skriver at problemene stammet fra en for privilegert standardrolle, og at AWS sikkerhetsteam har patchet problemene etter ansvarlig varsling.

Det gjør saken mer interessant enn et vanlig enkeltstående kodehull. Når flere agenter deler konto, region eller tilgangsmodell, kan en feil i én offentlig kundeserviceagent få konsekvenser for en intern økonomiagent. Forskerne sier at de kunne lese samtaler, minne og kode fra andre agenter de ikke var ment å bruke. Zenitys pressemelding beskriver også tilgang til API-nøkler, OAuth-tokens og andre lagrede legitimasjoner i testscenarioet.

Minnet kunne gjøre kapringen varig

Et spesielt alvorlig funn handler om agentminne. I en separat del av arbeidet viser Zenity hvordan en angriper kunne plante en instruks i minnet, slik at den påvirket senere samtaler uten å bli gjentatt i den aktive dialogen. Forskerne beskriver også et oppsett der agenten hentet nye instruksjoner fra en ekstern side og sendte samtaleinnhold til et endepunkt de kontrollerte.

Det betyr ikke at agentminne automatisk er usikkert. Det betyr at minne må behandles som data med høy integritetsrisiko, ikke som en uskyldig notatblokk. En tekst som er lagret som brukerpreferanse eller tidligere beslutning, kan få samme påvirkning på en agent som en systeminstruks dersom arkitekturen ikke skiller mellom kilder og tillitsnivåer. For alle som bygger agenter med automatisering og agentarbeid, er dette en påminnelse om at kontekst også er en angrepsflate.

AWS: Sikre med minste privilegium

AWS’ egen dokumentasjon sier at kode eller en aktør inne i AgentCore-mikroVM-en kan få tilgang til kjørerollens legitimasjoner via metadata-tjenesten. Derfor skal kjørerollen begrenses til bare ressursene og handlingene agenten trenger. AWS’ sikkerhetsveiledning anbefaler også egendefinerte IAM-policyer i produksjon, fullstendige ressurs-ARN-er fremfor brede jokertegn og kontroll av hvem som kan starte en agent.

• Roller: Gå gjennom hver AgentCore-kjørerolle og fjern tilgang som ikke trengs for den konkrete agenten.
• Legitimasjoner: Unngå å legge API-nøkler og passord direkte i agentkode, og bruk en løsning for identitet og hemmeligheter med avgrenset tilgang, slik AWS anbefaler.
• Minne og logging: Skill mellom brukerdata, instruksjoner og systemkonfigurasjon. Overvåk uventet lesing, skriving og kall mellom agenter.
• Miljøer: Skill offentlige og interne agenter etter konto, region eller andre tydelige tillitsgrenser når risikoen tilsier det.

Hva norske bedrifter bør gjøre nå

Norske virksomheter som ikke bruker AgentCore direkte, trenger ikke gjøre en panikkendring. Men samme mønster kan oppstå i andre agentplattformer: en offentlig inngang med verktøytilgang, en delt rolle, et minne som kan skrives til, og manglende kontroll på hvilke agenter som kan kalle hverandre. Derfor bør sikkerhetsteam vurdere arkitekturen, ikke bare navnet på tjenesten.

En konkret sjekk er å tegne hele kjeden fra brukerens melding til modell, verktøy, skytjenester, lagrede samtaler og andre agenter. For hvert steg bør virksomheten vite hvilken identitet som brukes, hvilke data som kan leses, og hvem som kan stoppe handlingen. AWS beskriver også at AgentCore ikke automatisk knytter sesjoner til bestemte brukere; den koblingen må håndteres av virksomhetens egen backend, ifølge sikkerhetsveiledningen.

Dette betyr det for norske brukere og bedrifter

For norske utviklere er AgentCorruption først og fremst en beskjed om å behandle AI-agenter som privilegerte applikasjoner, ikke som vanlige chatbotter. For ledelsen handler det om å kreve dokumentert tilgangsstyring, logging og avgrensning før agenter kobles til CRM, økonomi, HR eller kundedata. Zenity opplyser at AWS har patchet problemene, mens AWS’ oppdaterte sikkerhetsveiledning fortsatt krever minste privilegium og tydelig avgrensede roller. En leverandørpatch fjerner ikke brede IAM-roller eller svak intern segmentering hos kunden.

Ofte stilte spørsmål

Hva er AgentCorruption? AgentCorruption er navnet Zenity Labs har gitt en kjede av sikkerhetsproblemer i Amazon Bedrock AgentCore. I et kontrollert testoppsett kunne forskerne bruke én offentlig agent som inngang til andre agenter, samtaler og skylegitimasjoner, ifølge Zenitys rapport.

Er AWS AgentCore fortsatt trygt å bruke? Zenity opplyser at AWS har patchet problemene etter ansvarlig varsling. AWS anbefaler samtidig minste privilegium, egendefinerte IAM-policyer og avgrensede roller i produksjon. Se AWS’ sikkerhetsveiledning før du vurderer egen installasjon.

Hva bør en virksomhet sjekke først? Start med AgentCore-kjøreroller, wildcard-tilganger, lagrede hemmeligheter, minnefunksjoner og hvilke agenter som kan kalle hverandre. AWS anbefaler å begrense rollene til konkrete ressurser og handlinger, slik det står i dokumentasjonen.