Amazon ruller nye kontrolfunktioner ud i Bedrock AgentCore: en central gateway med rate limiting og temporale politikker, som vurderer rækken af agentens handlinger over tid i stedet for enkeltkald. AWS henviser til McKinsey for bagtæppet: omtrent 80 procent af organisationer har oplevet risikabel agentadfærd, og sikkerhed er største barriere for skalering. For danske teams handler det ikke om hype, men om håndværk: hvad kan flyttes ind i infrastrukturen nu, og hvad skal fortsat ejes i applikationerne?
For it- og sikkerhedsgrupper er det et konkret valg: gør gatewayen til håndhævelsespunkt. Det påvirker fejlretning, cost-kontrol og hvilke beviser man kan levere i revision.
Hvorfor nu
Agenter træffer selvstændige valg og kalder værktøjer i kæder. Isoleret er et kald uskadeligt; over en session kan mønsteret være problemet. AWS’ eksempler er nøgterne: små køb under godkendelsesgrænsen, spredte overførsler eller retries der æder budgettet natten over. Klassiske guardrails godkender hvert trin. Helheden glider igennem, fordi historikken ikke indgår i afgørelsen.
Temporale politikker forsøger at lukke hullet ved at “huske” tidligere trin i samme session og lade det påvirke næste handling. Ikke magi. Bare state og regler på tværs af kald.
Hvad er AgentCore
AgentCore er AWS’ platformlag for agentdrevne apps. Kernen er en fuldt styret, serverless gateway som indgangspunkt for AI-trafik. Den ruter til MCP-servere, modeller, agenter og videnbaser. Fordi alt passerer den vej, bliver den det naturlige sted at håndhæve politikker og forbrugslofter — ensartet på tværs af teams.
Nyt i pakken er to ting: rate limiting i gatewayen og temporale politikker drevet af Dogwood, et open source-policy-sprog målrettet agenter. Pointen er central, deterministisk kontrol uden at hvert team genskaber den i kode.
Temporale politikker i praksis
Stateless autorisation svarer kun på “må dette værktøj kaldes nu”. Temporale politikker supplerer med “hvad er allerede sket i denne session”. Det kræver et sessionslager af hændelser, en policy-motor og et sprog der kan referere bagud i tidslinjen.
Dogwood er præsenteret af AWS som open source og bygget til den opgave. AWS’ materiale skitserer mønstre som: kræv match mellem et tidligere læst kontonummer og et senere overførselskald; stop næste bestilling når sessionsbudgettet er ramt, selv om ordren i sig selv er under grænsen; håndhæv trinorden; kræv registreret menneskelig godkendelse før en irreversibel handling. Reglerne ligger i gatewayen, uden for agentens egen kode og prompts. Offentlig syntaks er ikke gennemgået i AWS-bloggen; link til Dogwood-specifikationen bør tilføjes ved publicering.
Gateway og rate limiting
Gatewayen er enforcement-punktet. Fuldt styret og placeret dér, hvor alt alligevel passerer. Rate limiting kan sættes pr. agent, identitet, værktøj og tidsvindue — ikke kun på netværkslag, men også for model- og værktøjskald.
Der er drift i det her. Politikevaluering og historikopslag lægger latens på. Gennemløb kan flade ud, hvis standardgrænser er stramme. Gevinsten er bedre observability — mod prisen at man skal have styr på logretention, felter og analyseflow. Tuning er løbende.
Sikkerhed og governance
Infrastrukturcentreret håndhævelse reducerer variationen fra ad hoc-guardrails. VentureBeat peger samtidig på det lavpraktiske: agenter opfører sig som arbejdsidentiteter og bør behandles sådan med onboarding, entitlements, navngiven ejer og offboarding. Uden ejerskab og scope ender man med “shadow AI”, der er umulig at revidere, uanset hvor stærk gatewayen er.
Identitet, scope og audit hænger sammen. Hvis en agent kan oprette Jira-sager, interagere med Salesforce eller provisionere infrastruktur, skal der være et spor der knytter handlingen til identitet og begrundet tilladelse.
Hvad det ikke løser
Temporale politikker fanger mønstre. De fanger ikke uklar forretningslogik, fejltolkning af data eller hallucinationer, der ligner sunde kald. Komplekse compliance-krav på tværs af systemer kræver ofte domænekontekst uden for gatewayen.
Og politikdesign er svært. For snævre regler blokerer legitime undtagelser. For brede lader risici passere. Der skal være testdata, evalueringskørsler og en ejerkreds for policy-ændringer — ikke bare en pæn YAML-fil i et repo.
Konsekvenser for danske virksomheder
Har I agenter i drift med adgang til penge, følsomme data eller kundekontakt, så prioriter en central gateway — AgentCore eller et eget lag. Enkeltkalds-guardrails ser ikke sekvensrisici, og det er netop dér, de dyre fejl opstår.
Start med få, skarpe temporale regler med høj effekt: sessionsbaserede forbrugslofter, værdimatch mellem læs og skriv, og krav om menneskelig godkendelse før irreversible trin. Hold scope snævert i første iteration og udvid ud fra data.
Implementering der virker
Det her er en driftsdisciplin, ikke en toggle. Aftal ejerskab af policybibliotek og evalueringsdata. Læg en fast rytme for red-teaming af agenterne og dokumentér bypass-mønstre.
Afklar integration tidligt: hvor lander logs, hvilket format, hvilke felter kræver revision, og hvordan korreleres gateway-afslag med events i ERP eller CRM. De valg afgør om platformen letter arbejdet eller bare flytter byrden over i SIEM-teamet.
Tjekliste før udrulning
- Uge 0–4 — Risiko-audit. Ejer: SecOps. Prioritet: høj. Succeskriterier: kortlagt dataklasser, værktøjer og agent-handlinger; kendte no-go-zoner dokumenteret.
- Uge 2–6 — Identitet og scope. Ejer: IAM/IT. Prioritet: høj. Succeskriterier: oprettede ikke-menneskelige identiteter med navngivne ejere, mindst mulige rettigheder og defineret offboarding.
- Uge 4–8 — Policy-prototyper. Ejer: Platform/Arkitektur. Prioritet: medium-høj. Succeskriterier: 3–5 temporale regler, reviewet af forretningsansvarlige, med tests og beskrivelser.
- Uge 6–10 — Testpipeline. Ejer: QA/ML Ops. Prioritet: medium. Succeskriterier: syntetiske sekvenser og real-world replays i CI; mål p50/p95/p99-latens for kald med og uden politik-evaluering.
- Uge 8–12 — Observability. Ejer: SRE/DevOps. Prioritet: medium. Succeskriterier: central logning med retention og adgangsstyring; dashboards for policy-hit rate og sekvensmønstre.
- Løbende — Red-teaming. Ejer: SecOps + App-teams. Prioritet: høj. Succeskriterier: dokumenterede bypass-fund, lukkede gaps og versionsstyrede policy-ændringer.
Drift og omkostninger
Omkostningerne ligger i sekvenser: gentagne modelkald, tool-invokationer og retriever-slag. Rate limiting hjælper, men kræver konfiguration og justering for at undgå falske positiver. Et loft pr. minut er sjældent nok; styring pr. session, pr. agent og pr. værktøj — bundet op på forretningsværdi — bliver hurtigt nødvendigt.
Valider modeller, prompts og kæder løbende. Små ændringer kan tippe et mønster over en tærskel og trigge uventede policy-stop. Læg CI for agenter ind, selv om det føles tungt; det er billigere end fejlsøgning i regnskab og logs bagefter.
Ydelse og PoC-målepunkter
AWS’ blogindlæg deler ikke konkrete tal for latency-overhead, throughput og omkostningsprofil for gatewayen. Planlæg derfor egne benchmarks i PoC: mål p95/p99-latens for typiske sekvenser, gennemløb ved stigende samtidighedsniveauer og fejlprocenter ved forskellige policy-typer. Track også tokenforbrug pr. session før og efter rate limiting.
Definér stopkriterier på forhånd: maksimal acceptabel p99-latens for kritiske flows og mindstekrav til gennemløb ved spidsbelastning. Ellers bliver “det føles langsomt” til en endeløs debat.
Compliance og revision
Revisorer og DPO’er forventer auditable logs, reproducerbare policy-evalueringer og tydelige koblinger mellem identitet, handling og afgørelse. En central gateway kan samle beslutningerne ét sted og dokumentere dem konsistent — hvis retention, dataplacering og adgangskontrol er defineret tidligt.
Når håndhævelsen flytter ud af applikationen, skal politikker versionsstyres med ændringshistorik og godkendelser. Det er nyt for mange udviklingsteams, men nødvendigt for et robust revisionsspor.
Leverandørvalg og multi cloud
En cloud-baseret enforcement-løsning giver fart og ensartethed, men øger risikoen for lock-in, især hvis politikker og logs ikke er portable. MCP og lignende protokoller kan holde værktøjsintegrationer mere mobile, men policy- og loglaget er sjældent 1:1-flytbare.
Et pragmatisk kompromis er et internt abstraktionslag til politikker og events: lad AgentCore håndhæve, men behold en uafhængig eventstrøm og et versionsstyret policy-repo, som principielt kan fødes til en anden gateway ved behov.
Modargumenter og alternativer
Nogle vil blive på applikationsniveauet for lavere latens og tættere domænekontekst. For simple agenter kan det være rimeligt. En hybridtilgang er ofte bedst: basis-politikker og rate limiting i gatewayen, domænespecifik validering i appen. Ulempen ved kun app-niveau er fravær af en central auditvej, når agenter håndterer penge, data eller kundeoplevelser.
Vigtig pointe: central håndhævelse erstatter ikke god domænelogik.
Kilder og verifikation
Produktfunktionerne — gateway, MCP-routing, temporale politikker via Dogwood og rate limiting — fremgår af AWS’ gennemgang af AgentCore. McKinsey-tallet om cirka 80 procent organisationer med risikabel agentadfærd er citeret via AWS; link til den originale McKinsey-rapport bør tilføjes ved publicering for læserverifikation. VentureBeat bidrager med praksiskrav om identitet, scoping og accountability samt henvisning til JumpCloud-data om vækst i ikke-menneskelige identiteter. Dogwood præsenteres som open source i AWS-materialet; link til specifikationen og syntaks-eksempler bør tilføjes, da AWS-bloggen ikke rummer dyb syntaks.
Der mangler uafhængige benchmarks for latency og throughput. PoC-tests er derfor påkrævet, før man fastlægger SLO’er.
Konklusion og næste skridt
AgentCore flytter kontrollen derhen, hvor sekvensrisici kan ses og stoppes. Det er brugbart — især når agenter får rigtige rettigheder. Tre konkrete next steps: 1) kør en 8–12 ugers PoC med gateway-håndhævelse og faste p99-mål, 2) implementér 3–5 temporale regler med høj effekt og versionsstyring, og 3) etabler central logning med defineret retention og adgangskontrol. Forskellen mærkes først under last, ikke på whiteboardet.
