Dogwood og nyt politiksprog i AgentCore

Den første og mest markante nyhed er temporale politikker bygget på et internt AWS-system kaldet Dogwood. Hvor en klassisk adgangspolitik svarer på spørgsmålet "må denne agent gøre X lige nu", svarer en temporal politik på "må denne agent have gjort X så mange gange inden for det seneste tidsrum". Det lyder som en lille forskel, men det er den forskel, der afgør, om man kan stole på en agent, der kører uovervåget i timevis eller dage.

I praksis betyder det, at man kan sætte grænser som "maksimalt 200 skrivninger til denne database per time" eller "maksimalt 50 dollars i modelforbrug per agentsession", og AgentCore håndhæver grænsen deterministisk, uden at man selv skal bygge tælle- og alarmlogik oven på agenten. Det er en markant forskel fra i dag, hvor de fleste teams enten stoler blindt på agentens egen dømmekraft eller bygger skrøbelige overvågningsscripts ved siden af.

Sammen med de temporale politikker lancerer AWS et open source-politiksprog, som lader teams skrive kontrolreglerne som kode i stedet for at klikke dem sammen i en konsol. Det betyder, at en sikkerhedsansvarlig kan skrive en politik som "denne agent må kalde betalings-API'et højst tre gange per bruger per dag" i et format, der kan versionsstyres, code-reviewes og genbruges på tværs af projekter.

Det at sproget er open source, betyder også, at politikker skrevet til én AgentCore-opsætning i princippet kan flyttes eller genbruges i andre sammenhænge, og at community kan bidrage til, hvilke mønstre der bliver standard. For virksomheder, der bygger flere agenter på tværs af afdelinger, er det forskellen på at genopfinde kontrolregler hver gang og på at have et fælles sprog, som både udviklere og compliance-folk kan læse.

Den tredje del af opdateringen er rate limiting flyttet ud til selve AgentCore Gateway, altså det lag, hvor agenter rent faktisk kalder værktøjer og eksterne systemer. Det betyder, at en grænse kan håndhæves centralt for alle agenter, der går gennem gatewayen, uden at hver enkelt agent skal implementere sin egen throttling.

Det løser et konkret problem: når flere agenter deler de samme underliggende ressourcer, et internt API, en database, en betalingsudbyder, er det gatewayen og ikke den enkelte agent, der skal vide, hvor grænsen går. Med rate limiting på det niveau kan man forhindre, at én overivrig agent spiser hele kvoten for et delt system, og man kan se belastningen samlet i stedet for spredt ud over dusinvis af individuelle agentlogfiler.

De tre nyheder, temporale politikker, det åbne politiksprog og gateway-rate limiting, løser tilsammen det samme underliggende problem fra tre vinkler: hvordan holder man styr på en agent, der handler selvstændigt over tid, uden at bremse den unødigt.

For virksomheder, der allerede har agenter i drift, er den praktiske konsekvens, at man kan gå fra reaktiv overvågning, hvor man opdager problemer efter de er sket, til proaktiv styring, hvor grænserne er indbygget i platformen fra starten. Det gør det lettere at sætte konkrete omkostningslofter på agentforbrug, hvilket ofte er den største barriere for at give agenter mere selvstændighed i produktion. Når man kan stole på, at en agent ikke kan løbe løbsk økonomisk eller adfærdsmæssigt, bliver det også lettere at retfærdiggøre at give den mere ansvar.