AWS Adds Temporal Policies to Bedrock AgentCore to Stop AI Agents From Exploiting Multi-Step Actions

What's New

Amazon Web Services has introduced temporal policies in Amazon Bedrock AgentCore, a security feature that lets enterprises enforce authorization rules based on an AI agent's full session trajectory rather than evaluating each tool call in isolation. The capability runs at the AgentCore Gateway perimeter, outside the agent's own code, meaning agents cannot intercept, inspect, or manipulate the policy logic regardless of prompting or bugs.

The Problem AWS Is Addressing

Traditional access controls treat each action as independent. AI agents break this model because they decide at runtime which tools to call, in what order, and with what arguments. AWS cites three failure scenarios that existing stateless controls miss entirely:

• An agent calls lookup_customer, hallucinates a different account number, then passes it to transfer_funds—moving money to the wrong account.
• A runaway agent executes dozens of trades in a loop with no tracking of cumulative risk exposure.
• An agent both approves and denies the same insurance claim within seconds.

Each individual tool call in these cases would pass a stateless policy check. According to AWS, the problem only surfaces when examining the agent's full trajectory—the ordered sequence of actions within a session.

How Temporal Policies Work

Temporal policies extend AgentCore's existing Policy engine, which already handles stateless, deterministic rules (who can call which tool, under what conditions). The new layer adds trajectory awareness. According to AWS, the system:

1. Queries trajectory state for actions, inputs, and outputs relevant to the policies being checked.
2. Evaluates each temporal policy against the current request in context of prior events in the defined trajectory.
3. Returns a deterministic ALLOW or DENY decision and logs full decision context.

Policies deny by default, and forbid rules override permit rules—consistent with AWS's existing AgentCore Policy design. Every evaluated request must carry an x-amzn-bedrock-agentcore-policy-session-id header identifying the session. Developers define session boundaries (a single conversation, a multi-step task, or a longer workflow), and if no header is passed, AgentCore generates one with an empty trajectory.

AWS specifies several technical limits: sessions combine the session ID with end-user identity, so two different identities using the same session ID are treated as separate sessions. Trajectories carry a maximum look-back window of 24 hours, after which older events are automatically deleted. Any change to policies in a policy engine invalidates existing sessions, forcing re-evaluation against the current rule set.

Because AgentCore Gateway routes Model Context Protocol (MCP) tool calls, agent-to-agent calls, and model inference calls through a single endpoint, a temporal policy can govern all three types of traffic simultaneously.

Example Use Case

AWS walks through a hypothetical private banking agent used by wealth advisors, which retrieves client profiles, loads portfolio holdings, fetches market prices, and executes trades via tools like get_client_profile, load_portfolio, and get_market_price. Temporal policies in this scenario could enforce tool-call ordering (SOP adherence), require exact argument matching between chained tool outputs to prevent hallucinated substitutions, cap cumulative financial exposure per session, mandate human approval before high-value trades, and enforce data freshness windows for price lookups before executing dependent trades.

AWS did not disclose pricing for temporal policies as a standalone feature; it appears to be part of the broader Bedrock AgentCore Gateway and Policy offering.

What This Means

This is AWS extending enterprise governance tooling to match the non-deterministic nature of agentic AI. Stateless authorization—the model used for nearly all API and application security to date—assumes each request can be judged independently. Agents break that assumption because harm often emerges from sequences of individually-safe actions, not any single call. Placing enforcement at the gateway, rather than trusting agent code or prompts, is the right architectural choice: agents cannot talk their way around a control they never see. Expect competitors—Microsoft, Google, and the broader agent-framework ecosystem—to ship comparable trajectory-based enforcement soon, since financial services, healthcare, and other regulated industries will treat this class of control as a prerequisite for production agent deployment, not an optional add-on.