Securing AI agents with temporal policies in Amazon Bedrock AgentCore
AWS Sean Eichenberger ● Covered by 3 sources
AWS just gave AI agents a memory-aware bouncer. Bedrock AgentCore's new temporal policies check an agent's past actions, not just its current request, before letting it act.
Access control used to be simple: check the request, allow or deny, move on. AI agents broke that model. They pick their own tools, arguments, and order at runtime, which means a single action can look perfectly fine on its own but be dangerous given what happened three steps earlier. AWS's answer, detailed in a new Bedrock AgentCore feature, is something it calls temporal policies — authorization rules that judge a request against the agent's recent history rather than in isolation.
The motivating examples are the kind that keep compliance officers up at night. An agent looks up a customer account, hallucinates a slightly different account number, then wires money to the wrong person. A trading bot loops through dozens of orders without anyone tracking that it has blown past its risk limit. A claims agent approves and denies the same insurance claim within seconds of each other. None of these trip a standard, stateless rule check, because each individual tool call is technically legitimate. The problem only shows up when you look at the full sequence, or as AWS calls it, the trajectory.
Temporal policies sit at the AgentCore Gateway, outside the agent's own code, which is the part that actually matters. The agent can't see the policy logic, touch the state store, or talk its way around the rules no matter how it's prompted. Every session gets tracked by a header tied to both a session ID and the caller's identity, with a rolling 24-hour lookback window, and any policy change wipes existing sessions so nothing gets evaluated against outdated rules. The system defaults to deny, and a forbid always beats a permit — standard zero-trust logic, just applied to a moving sequence of actions instead of a single request.
AWS walks through a private banking agent to show this in practice, using Cedar-compatible policies written in a new open-source language called Dogwood. The rules read like an actual compliance checklist: pull the client profile and load the portfolio before any trade, make sure the portfolio ID in a trade exactly matches what the profile lookup returned, require a market price fetched within 30 seconds of execution, cap total session trading at $60,000, force human approval above $25,000, block a same-session buy-then-loss-sell of the same security, and strip write access after 15 minutes of advisor inactivity. Each rule targets a specific failure mode — hallucinated IDs, stale prices, runaway loops, unsupervised drift — that a plain stateless check would wave through.
What's notable here isn't the individual rules, which are fairly obvious once spelled out. It's that AWS is building this directly into the gateway layer rather than leaving it to developers to bolt on their own session tracking and hope the agent respects it. Given how much of the current agent-safety conversation revolves around prompt injection and tool misuse, putting enforcement somewhere the model literally cannot reach is a meaningfully different posture than trusting the system prompt to behave.
My take
This is the boring, unglamorous work that actually matters for agents doing real financial or operational tasks, and it's a relief to see AWS ship enforcement at the infrastructure layer instead of another paper about alignment. Prompt-level safety measures were always going to be a losing game against a sufficiently motivated injection attack; putting the guardrails where the model can't see or touch them is the correct instinct, and every other cloud provider chasing agent workloads is going to need an equivalent story fast.
Read more about this at: AWS
