AWS strammer inn hemmeligheter for AI-agenter

AWS har lagt inn en liten, men viktig endring i Amazon Bedrock AgentCore Identity: AI-agenter kan nå bruke eksisterende hemmeligheter i AWS Secrets Manager når de skal autentisere seg mot eksterne API-er.

Det høres smalt ut. Det er det ikke. Dette er en av de praktiske sperrene som avgjør om agentprosjekter kan flyttes fra demo til produksjon uten at sikkerhetsteamet får migrene.

AgentCore Identity kunne allerede opprette og håndtere hemmeligheter for outbound credential providers. Nyheten er at virksomheten kan peke AgentCore mot en hemmelighet som allerede ligger i Secrets Manager. Det kan være en API-nøkkel eller en OAuth client secret. Dermed kan agenten hente legitimasjon ved runtime, mens organisasjonen beholder styringen på kryptering, rotasjon, tags, resource policies og revisjon.

For CIO og CISO er poenget enkelt: Når agenter får lov til å bruke verktøy, blir de også en ny type integrasjonsbruker. De skal hente data fra CRM, skrive til Slack, åpne GitHub-repoer, slå opp saker i interne systemer og kalle tredjeparts-API-er. Da må hemmelighetene styres som annen produksjonslegitimasjon. Ikke ligge i kode. Ikke lekke inn i prompts. Ikke flyte rundt i agentkonfigurasjon uten eier, rotasjon og tilgangskontroll.

Hvorfor dette betyr noe

AWS beskriver endringen som en måte å videreføre eksisterende governance-prosesser til AgentCore. Det er den riktige vinkelen. Mange virksomheter har allerede standarder for Secrets Manager, KMS-nøkler, tagging, ressurs-policyer og rotasjon. Agentprosjektene bør inn i de løypene, ikke få en parallell sikkerhetsmodell fordi teknologien er ny.

Med den nye funksjonen kan en eksisterende secret brukes direkte når man oppretter credential provider resources i AgentCore Identity. Hvis verdien roteres i Secrets Manager, henter AgentCore Identity den oppdaterte verdien neste gang den leser hemmeligheten. AWS sier også at det er mulig å bruke en secret fra en annen AWS-konto innen samme region. Kryssregion-deling støttes ikke.

Det siste er verdt å merke seg. Store virksomheter skiller ofte plattform, sikkerhet og applikasjonsteam i ulike kontoer. At agentidentitet kan lese fra en annen konto i samme region gjør det lettere å beholde sentral kontroll uten å kopiere hemmeligheter til hvert team. Samtidig holder AWS igjen på kryssregion. Det betyr at global agentdrift fortsatt må planlegges rundt region, datalagring og kontrollgrenser.

AWS peker også på støtte for hemmeligheter som kommer inn via AWS Secrets Manager external connectors. Det åpner for integrasjon med tredjeparts secret managers, men uten at AgentCore må få sin egen uavhengige hemmelighetsflyt. Det er sunnere arkitektur enn å la hver agentplattform lage sin egen lille passordbank.

Fra prompt-sikkerhet til driftssikkerhet

Mye av AI-sikkerhetsdebatten handler fortsatt om prompt injection, modellatferd og data som sendes inn i modeller. Det er viktig. Men produksjonsagenter feiler ofte på mer ordinære ting: identiteter, nøkler, roller, logging, endringsstyring og hvem som faktisk får lov til å gjøre hva.

Denne AWS-endringen handler om akkurat det laget. En agent som kan kalle et eksternt API må ha en legitim kanal for autentisering. Hvis den kan lese en nøkkel, må tilgangen være avgrenset. Hvis nøkkelen roteres, må agenten overleve rotasjonen. Hvis revisor spør hvorfor en bestemt secret brukes, må tags, policy og logg gi svar.

For regulerte miljøer er dette ikke pynt. AWS fremhever bruk av kundestyrte KMS-nøkler. Det gjør at organisasjoner som krever egen nøkkelhåndtering kan opprette hemmeligheten før AgentCore kobles på, og beholde krypteringsoppsettet. Resource policies i Secrets Manager kan brukes til å avgrense hvilke IAM-prinsipaler som får lese hemmeligheten.

Det gjør ikke agenten trygg alene. Men det flytter en viktig del av risikoen inn i kjente kontrollflater. CISO får færre særregler. Plattformteamet kan bruke eksisterende drift. Applikasjonsteamet slipper å bygge egen håndtering av OAuth client secrets og API-nøkler for hver agent.

Hva norske virksomheter bør gjøre

Dette er ikke en grunn til å kjøpe AgentCore alene. Det er en grunn til å stramme inn kravlisten for alle agentplattformer.

Spør leverandøren hvordan agenter håndterer hemmeligheter. Kan de bruke eksisterende secret manager? Støttes rotasjon uten redeploy? Kan tilgang styres med IAM eller tilsvarende policy? Finnes det revisjonslogg for når legitimasjon leses? Kan hemmeligheter merkes og knyttes til systemeier, koststed og compliance-krav? Kan agenten begrenses til en konkret secret og et konkret verktøy?

Hvis svaret er uklart, er ikke løsningen produksjonsklar. Da er agenten fortsatt en demo med for mye makt.

For AWS-kunder er den praktiske konsekvensen at Bedrock AgentCore nå passer bedre inn i eksisterende sikkerhetsarkitektur. For alle andre er signalet bredere: Agentstyring blir raskt ordinær IAM-, secrets- og runtime-drift. Det er bra. AI-agenter bør ikke behandles som magi. De bør behandles som programvare med nøkler, rettigheter og ansvar.

Kilder og medier

Primærkilde: AWS Machine Learning Blog, "Reference your own AWS Secrets Manager secrets in Amazon Bedrock AgentCore Identity", publisert 1. juni 2026: https://aws.amazon.com/blogs/machine-learning/reference-your-own-aws-secrets-manager-secrets-in-amazon-bedrock-agentcore-identity/

Thumbnail: OpenAI Image 2 / hogby.ai