Stateful Security for AI Agents with Amazon Bedrock AgentCore

Introduction

Before AI agents became common, access control was largely stateless: each action could be evaluated independently of what came before. AI agents break that assumption. They decide at runtime which tools to call, with what arguments, and in what sequence, which makes them powerful but harder to govern. A single tool call can look safe in isolation, yet be dangerous in the context of an earlier step, such as a call that follows a read from an untrusted data source. Securing agents requires authorization rules that account for session history in a way that the agent itself cannot bypass.

This blog introduces temporal policies in Amazon Bedrock AgentCore, which allow teams to define stateful rules evaluated against an agent’s prior trajectory rather than against a single, isolated request. Using a hypothetical private banking portfolio agent as an example, it walks through policy patterns that enforce workflow sequencing, protect against data fabrication, cap financial exposure, and require human approval for sensitive actions.

Why Agents Need Stateful Policy Enforcement

Existing controls in AgentCore Policy already enforce stateless rules that determine which principal can call which tool under which conditions. These checks are necessary, but not sufficient, for agentic systems. An agent could hallucinate an account number and pass it into a funds-transfer tool, moving money to the wrong account. A malfunctioning agent could execute trade after trade in a loop with nothing tracking that cumulative exposure has blown past a risk limit. Each action would pass a stateless check on its own, because the problem only becomes visible when you look at the full trajectory, the ordered sequence of everything the agent has done in a session.

Temporal policies extend Policy in Amazon Bedrock AgentCore with this trajectory-aware layer. Because they run at the AgentCore Gateway perimeter rather than inside the agent’s own code, they cannot be bypassed, no matter how the agent is prompted or what bugs exist in its logic. Common use cases include requiring an argument to match the output of a prior tool call, enforcing that certain tools run in a specific order, blocking privileged actions until a human approval event appears in the trajectory, and requiring a data lookup to be recent enough before a dependent action is authorized. Because AgentCore Gateway routes an agent’s Model Context Protocol tool calls, agent-to-agent calls, and model inference calls through one endpoint, a single policy can govern all three.

How Temporal Policies Work

Temporal policies build on the same policy engine used for stateless access control, adding the concept of an agent trajectory: a bounded sequence of actions associated with a principal and a session ID. Agents never see the underlying policy logic or state store, and they cannot alter the rules. Like other AgentCore Policy controls, temporal policies deny by default, and any explicit forbid rule wins over a permit.

When AgentCore Gateway receives a tool call, the policy engine queries the trajectory state for relevant prior actions, evaluates each applicable policy against the current request in that historical context, and returns a deterministic allow or deny decision while logging the full context behind it. Every evaluated request carries a session identifier, and the boundary of a session, whether a single conversation or a longer workflow, is left to the customer. AgentCore combines that session ID with the end user’s identity, so two identities presenting the same session ID are still evaluated independently. Trajectories retain a maximum look-back window of 24 hours, and any change to a policy engine’s rules invalidates existing sessions.

Applying Temporal Policies to a Private Banking Agent

Consider a wealth-management agent that retrieves client profiles, loads portfolio holdings, fetches market prices, and executes trades through tools on AgentCore Gateway. A compliance team might require seven controls before production: retrieve the client profile and load the portfolio before any trade; match the portfolio ID used in a trade against the profile lookup; refresh market prices within a short window before a trade; cap cumulative trade value per session; require one-time advisor approval above a threshold; block buying back a security just sold at a loss; and revoke write access after a period of advisor inactivity.

Each pattern targets a different risk. Sequencing rules stop an agent from skipping required context. Output-to-input integrity checks prevent prompt injection from substituting a fabricated value between calls. Freshness rules keep decisions grounded in current data. Cumulative caps contain damage from a runaway agent. Approval and mutual-exclusion rules add human oversight and catch contradictory behavior. Progressive trust decay narrows permissions the longer an agent operates without a human present.

Implementation and Cost Considerations

Rolling out temporal policies alongside existing stateless rules can be gradual: an existing policy engine or individual policies can run in log-only mode first, so teams can observe how new rules would behave before enforcing denials in production. Because deleting or changing a policy invalidates in-flight sessions, changes are best made between active workloads. Temporal policy checks are billed as part of the existing per-authorization-request cost, and each policy engine includes an initial allotment of temporal policies at no extra charge.

Conclusion

Stateless access control was built for applications that acted predictably, one request at a time. Agents do not behave that way, since they choose their own tools, arguments, and order at runtime, and a single call can only be judged safe or unsafe in light of what happened before it. Temporal policies in Amazon Bedrock AgentCore close that gap by evaluating requests against an agent’s trajectory at the AgentCore Gateway perimeter, giving teams a declarative, auditable way to enforce sequencing, integrity, freshness, budget limits, approval, and trust decay without constraining the flexibility that makes agents useful. That combination of tamper-proof enforcement and session-aware context is what turns a capable agent into one that can be trusted with real actions and real consequences.

Drop a query if you have any questions regarding Amazon Bedrock AgentCore, and we will get back to you quickly.