AWS flytter agentkontroll ut av selve agenten

AWS gjør et viktig skifte i hvordan produksjonsagenter kan styres. I en ny oppdatering til Amazon Bedrock AgentCore beskriver selskapet temporal policies og rate limiting i gatewayen. Poenget er enkelt: en agent skal ikke bare vurderes på hvert enkelt kall. Den må vurderes på mønsteret av handlinger over tid.

Det er en mer praktisk måte å tenke AI-risiko på. Mange agentprosjekter har hittil lagt for mye ansvar i selve agenten. Modellen skal forstå policyen, følge instruksen, stoppe når den bør stoppe og ikke bli lurt av konteksten. Det holder dårlig når agenten får verktøy, minne, nettleser, API-er og tilgang til systemer der feil handling faktisk flytter data, penger eller produksjonsflyt.

AWS beskriver flere konkrete sviktmodi. En agent kan hente kundedata og deretter overføre penger til et annet kontonummer. Hvert kall kan se legitimt ut isolert. Feilen ligger i sammenhengen. En agent kan legge flere bestillinger under en terskel, men samlet sprenge budsjettet. Den kan også gå i retry-sløyfe gjennom natten og spise tokenbudsjettet uten at noen grense stanser tempoet.

AgentCore Gateway blir derfor kontrollpunktet. Den ruter kall til MCP-servere, modeller, agenter og kunnskapsbaser. Når trafikken går gjennom samme port, kan plattformteamet håndheve regler på tvers av agentene. Det er mer robust enn å be hvert produktteam kode sin egen kontroll.

Den nye delen er temporal policies. De ser på agentens tidligere handlinger i samme økt før neste handling tillates. En regel kan kreve at load_portfolio bare får kjøre etter get_client_profile, og at rebalance_portfolio bare får kjøre etter at porteføljen faktisk er lastet. En annen regel kan kreve at en portefølje-ID som brukes i en handel, matcher en ID som kom fra et tidligere, verifisert kall. En tredje kan telle samlet beløp og stoppe neste transaksjon selv om den isolert er under grensen.

Dette er styring av handlingskjeder, ikke bare tilgangsstyring. For CISO-er er det forskjellen mellom å håpe at agenten tolker instruksen riktig og å vite at en ytre policy stanser uønsket sekvens. AWS skriver at reglene håndheves utenfor agentens egen kode, at agenten ikke ser policylogikken, og at beslutningene er deterministiske, deny-by-default og logget med kontekst.

Under panseret bruker AWS Dogwood, et nytt åpent policyspråk for AI-agenter. Dogwood bygger på Cedar og legger til tidsvinduer, krav til forhåndssteg, rategrenser og eskaleringstriggere. Det er ikke bare en AWS-detalj. Det peker mot en bredere standardisering av agentstyring, der virksomheter må kunne forklare hva agenten fikk lov til, hvorfor den ble stoppet, og hvilken bruker og økt handlingen tilhørte.

Rate limiting er den andre delen av oppdateringen. AWS lar team sette grenser på gatewaynivå for forespørsler, tokenforbruk og hvor lenge forbindelser kan holdes åpne. Det høres teknisk ut, men er et budsjett- og driftsstyringspunkt. Agentkostnader løper ikke som tradisjonell SaaS per sete. De løper med antall steg, kontekst, verktøykall og feilsløyfer. Et budsjett som bare ligger i økonomirapporten kommer for sent.

For norske virksomheter er dette særlig relevant i tre miljøer. Først finans, forsikring og offentlig sektor, der agenten kan lese sensitive data og foreslå eller utføre handlinger i samme økt. Der må sikkerhetsteamet kunne si: denne agenten kan bare handle etter disse trinnene, med denne brukeridentiteten, innenfor dette beløpet og med denne godkjenningen.

Deretter utviklings- og driftsteam som nå eksperimenterer med kodeagenter. Når agentene får terminal, GitHub, interne API-er og deployverktøy, er det for svakt å stole på prompten. En agent som leser utrygg dokumentasjon og deretter prøver å pushe kode eller hente secrets, må stoppes av et system utenfor modellen.

Til slutt gjelder det innkjøp. Mange leverandører selger nå agentplattformer med pene demonstrasjoner. Spørsmålet ledelsen bør stille er ikke om agenten kan løse oppgaven én gang i demo. Spørsmålet er hvordan plattformen kontrollerer sekvenser, kostnad, identitet, verktøykall, logging og menneskelig godkjenning når agenten går i produksjon.

Det finnes også en låserisiko. AgentCore er AWS. Virksomheter som allerede er tungt inne i Amazon-økosystemet får en naturlig vei. De som kjører multi-cloud eller ønsker leverandøruavhengighet bør likevel merke seg mønsteret: agentkontroll må ligge i infrastrukturen rundt modellen, ikke i modellens gode oppførsel. Om kontrollplanet heter AgentCore, Unity AI Gateway, Entra, en intern policyproxy eller noe annet, er mindre viktig enn at det finnes.

Det praktiske styrepunktet er derfor klart. Før flere agenter får skrive- og handlingsrettigheter, bør virksomheten lage en enkel kontrollmatrise: hvilke verktøy kan agenten bruke, i hvilken rekkefølge, på vegne av hvem, med hvilken kostnadsgrense, og når kreves menneskelig godkjenning. Hvis leverandøren ikke kan svare presist, er ikke agenten moden for kritiske prosesser.

AWS-oppdateringen er ikke en garanti for trygg agentdrift. Den er likevel et tegn på at markedet beveger seg fra fascinasjon til produksjonskontroll. Det er der de neste 12 månedene blir avgjørende: ikke hvem som har den smarteste demoagenten, men hvem som kan la agenten arbeide uten at økonomi, sikkerhet og revisjon mister grepet.

Kilder og medier

Kilde: AWS Machine Learning Blog, "Control agent behaviors and cost beyond a single action: new capabilities in Amazon Bedrock AgentCore", publisert 6. august 2026. https://aws.amazon.com/blogs/machine-learning/control-agent-behaviors-and-cost-beyond-a-single-action-new-capabilities-in-amazon-bedrock-agentcore

Thumbnail: OpenAI Image 2 / hogby.ai