{"slug": "securing-ai-agents-with-temporal-policies-in-amazon-bedrock-agentcore", "title": "Securing AI agents with temporal policies in Amazon Bedrock AgentCore", "summary": "Amazon Web Services (AWS) announced temporal policies for Amazon Bedrock AgentCore, a feature that enforces stateful authorization rules at the AgentCore Gateway perimeter, evaluating each request against the agent's session history to prevent circumvention. The policies address scenarios such as enforcing tool-call ordering, preventing data fabrication between calls, capping cumulative financial exposure, and requiring human approval for high-value actions. AWS positions this as a response to the unique challenges of AI agents, which decide tool calls at runtime and can be harmful when actions are considered in sequence rather than in isolation.", "body_md": "[Artificial Intelligence](/blogs/machine-learning/)\n\n# Securing AI agents with temporal policies in Amazon Bedrock AgentCore\n\nBefore AI agents, it was generally sufficient for access controls to treat each action as an independent event. Applications relied on deterministic business logic to enforce whether actions happened in the right order or whether the data was up-to-date. AI agents behave in fundamentally different ways than traditional applications. They decide at runtime which tools to call, with which arguments, and in what order. That flexibility, combined with increasingly intelligent models, makes agents equal measures capable and challenging to control. One tool call might be deemed safe when considered in isolation, but harmful in the context of the preceding call, such as after reading from an untrusted data source. The question then becomes, how do you enforce authorization rules that account for an agent’s session history, in a way the agent cannot circumvent?\n\n[Temporal policies](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy-temporal.html) in [Amazon Bedrock AgentCore](/bedrock/agentcore/) let you define stateful rules that determine authorization to [AgentCore Gateway](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html) targets by evaluating the current request in the context of prior events in an agent’s trajectory. Because these policies run at the AgentCore Gateway perimeter, outside the agent’s own code, the agent cannot intercept or manipulate them.\n\nIn this post, you will learn what temporal policies are, how they work, and walk through an example to demonstrate. We will show you how to use temporal policies to enforce workflow sequencing, prevent data fabrication between tool calls, cap cumulative financial exposure per session, and require human approval for high-value actions. You will also see how to automatically tighten permissions when an agent operates without human engagement. First, however, we will explore the needs and use cases for stateful policies in more detail.\n\n## Why agents need stateful policy enforcement\n\nExisting access controls in AgentCore Policy enforce stateless, deterministic rules on each individual request: who can call which tool, under what conditions. Stateless controls are necessary but often insufficient for agents. Consider the following scenarios where existing stateless controls fail to catch critical issues:\n\n- An agent calls a\n`lookup_customer`\n\ntool, hallucinates a different account number than what was returned, and passes it to a`transfer_funds`\n\ntool that then moves money to the wrong customer’s account. - A runaway agent executes dozens of trades in a loop because nothing tracks that cumulative exposure has already exceeded the risk limit.\n- An agent both approves and denies the same insurance claim within seconds.\n\nEach individual tool call in these scenarios would pass a stateless policy check. The problem only becomes apparent when you look at the agent’s trajectory, the ordered sequence of actions in a session. Temporal policies extend Policy in AgentCore with this trajectory-aware enforcement layer. Temporal policies run at the gateway, outside the agent’s code, so they cannot be bypassed regardless of what the agent does, how it is prompted, or what bugs exist in the agent code. Some common temporal policy use cases include:\n\n**Enforcing output integrity across chained tools.** Require that an argument passed to the current tool call exactly matches the output of a prior tool call, preventing the agent from hallucinating or substituting values between steps.**Enforcing tool-call ordering.** Require that one tool is called before another tool to verify standard operating procedure (SOP) adherence.**Requiring human approval before privileged actions.** Block destructive or sensitive tool calls until an explicit human approval event is recorded in the trajectory.**Enforcing data freshness.** Require that a data lookup completed within a given timeframe before a dependent action is authorized, preventing decisions based on stale information.Temporal policies are authorization controls that answer the question “given the recent trajectory observed at the AgentCore Gateway, is this specific request authorized?”. They evaluate whether a gateway-routed request should be permitted based on the current request*and*recent trajectory (that is, events within a session). They do not transform requests, call tools, perform analysis, or directly orchestrate the agent.\n\nTemporal policies operate on the traffic that flows through AgentCore Gateway. Because Gateway routes an agent’s 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 whenever your agent issues those calls through the gateway. This gives you one consistent place to reason about an agent’s behavior over time, regardless of which kind of call the agent is making.\n\n## How temporal policies work\n\nTemporal policies build on the existing policy engine that’s already used for stateless access control. They introduce the concept of agent trajectories, which are bounded sequences of actions identified by a [principal](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy-core-concepts.html#concept-principal-types) and session ID. Agents never see the policy logic, never touch the state store, and cannot alter the controls. As with the existing AgentCore Policy features, temporal policies deny by default and forbid wins over permit.\n\nWhen the gateway receives a tool call, the policy engine:\n\n- Queries the trajectory state for actions, inputs, and outputs relevant to the policies being evaluated.\n- Evaluates each temporal policy against the current request in the context of its historical scope (that is, prior events within the customer-defined trajectory).\n- Returns a deterministic ALLOW or DENY decision and logs the full context of the decision.\n\nEvery request that a temporal policy evaluates must carry an `x-amzn-bedrock-agentcore-policy-session-id`\n\nheader, which identifies the session the request belongs to. You decide what constitutes the beginning and end of a session. The boundary can reflect whatever unit of work makes sense for your application, whether that is a single user conversation, a multi-step task, or a longer-running workflow. Because there can be no more than one concurrent authorization request per session, we recommend keeping the scope of a session as narrow as possible. If no header is passed, one will be generated on your behalf. However, note that a new session ID means that the policy engine will evaluate against a new, empty trajectory with no history.\n\nA session is never defined by its ID alone. AgentCore combines the session ID with the end user’s identity to produce a unique session, which means two different identities can present the same session ID and still be treated as having entirely separate sessions. Policies apply independently to each trajectory, because the underlying identity differs. Within an active session, agent trajectories carry a maximum look-back window of 24 hours. Any trajectory events older than that are automatically deleted. One additional rule governs the relationship between sessions and the policies themselves. Whenever a change is made to the policies in a policy engine, existing sessions are invalidated. This makes sure that each session is evaluated against the current set of policies and each relevant trajectory event is recorded with the expected schema.\n\n## Applying temporal policies to a private banking portfolio agent\n\nTo make these concepts concrete, we’ll walk through how temporal policies can secure a hypothetical private banking agent. The agent helps wealth advisors at a financial services firm manage client portfolios. It retrieves client profiles, loads portfolio holdings, fetches real-time market prices, performs analysis, and executes trades on the advisor’s behalf.\n\nIn this scenario, the following MCP tools are exposed through the AgentCore Gateway:\n\nTool |\nDescription |\n| get_client_profile | Retrieves client’s risk tolerance, investment policy, account restrictions, and associated portfolio IDs |\n| load_portfolio | Retrieves a client’s portfolio holdings and current positions |\n| get_market_price | Fetches current market price for a security |\n| execute_trade | Executes a buy or sell order against a portfolio |\n| rebalance_portfolio | Adjusts portfolio allocations across holdings |\n\nThere are three different advisor roles: junior advisors (limited trade authority), senior advisors (full trade authority), and compliance officers (read-only monitoring access). In this example, we will use [Amazon Cognito](/cognito/) for identity and pass JWTs for inbound auth to the AgentCore Gateway, which hosts our agent’s tools. To learn about AgentCore Gateway and how to set up auth with Gateway, read the [AgentCore Gateway Documentation](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html). Temporal policies use [Dogwood](https://dogwood-policy.github.io/dogwood/index.html), a new open-source governance language designed for agents and their tools. Dogwood supports evaluating existing [Cedar policies](https://docs.cedarpolicy.com/) and enables support for temporal conditions. Because Dogwood is compatible with existing Cedar policies, customers can continue to use their current Cedar policies without needing to migrate. For additional detail on Dogwood and its semantics, you can read the [language documentation](https://dogwood-policy.github.io/dogwood/index.html) or [this blog post](/blogs/opensource/introducing-dogwood-runtime-verification-for-ai-agents/).\n\nThe compliance team requires the following temporal controls before the agent reaches production:\n\n- The agent must pull the client profile, then load the portfolio, before any trade executes.\n- The\n`portfolio_id`\n\nused in a trade must exactly match the output from`get_client_profile`\n\n. - Market prices must be retrieved within 1 minute of a trade execution.\n- No single session can exceed $60,000 in total trade value.\n- Any individual trade over $25,000 requires advisor approval, one approval per trade.\n- The agent cannot buy and then sell the same security within the same trajectory if it sells for a loss.\n- After 15 minutes without advisor interaction, the agent loses access to write operations.\n\n## Request flow through gateway and policy\n\nThis diagram demonstrates how requests to your gateway are intercepted and evaluated by Policy in AgentCore. When the portfolio agent initiates a tool call, the following steps occur:\n\n- The request arrives at the AgentCore Gateway. The advisor is already authenticated through AgentCore Identity. The request carries the trajectory ID for the current session.\n- The policy engine retrieves the trajectory’s accumulated state.\n- Each temporal policy evaluates the current request against that history.\n- If all policies permit, the request proceeds to the MCP tool. If any policy forbids, the request is denied and the denial is logged.\n- On successful execution, the action and its result are appended to the trajectory state for future evaluations.\n\n## Implementing temporal policies\n\nIf you have an existing policy engine in `ENFORCE`\n\nmode, you can either update its enforcement mode to `LOG_ONLY`\n\n, or you can change the enforcement mode of the individual policies. Switching existing policies or policy engines to `LOG_ONLY`\n\nmode is not recommended for production workloads since policies will no longer enforce those security rules.\n\n### Prerequisites\n\nBefore implementing this solution, verify that you have met the following prerequisites:\n\n- An active AWS account with Amazon Bedrock AgentCore enabled.\n- An AgentCore Gateway with at least one MCP target configured.\n- A policy engine attached to the gateway.\n- Appropriate Identity and Access Management (IAM) permissions to create and manage policy resources (see documentation).\n\n### Policy 1: Workflow sequencing (multi-hop chain)\n\nThe compliance team requires that the agent follow `get_client_profile`\n\n, then `load_portfolio`\n\n, then `rebalance_portfolio`\n\nin sequence. Without the client profile, the agent has no system-verified context about which portfolios belong to this client, what the client’s risk tolerance is, or what account restrictions apply.\n\nThis policy forbids `rebalance_portfolio`\n\nunless `get_client_profile`\n\nand `load_portfolio`\n\nhave both completed in the correct order within this trajectory. An agent that skips the load profile step and jumps directly to rebalancing is denied regardless of what instructions it received.\n\nTrajectory state |\nAction attempted |\nExpected result |\n| Empty | rebalance_portfolio (portfolio_id: ” 8821”, amount: 15000) | DENY |\n| get_client_profile completed | rebalance_portfolio (portfolio_id: ” 8821”, amount: 15000) | DENY |\n| get_client_profile then load_portfolio completed | rebalance_portfolio(portfolio_id: ” 8821”, amount: 15000) | ALLOW |\n\n### Policy 2: Output-to-input integrity\n\nThe `portfolio_id`\n\npassed to `execute_trade`\n\nmust exactly match one of the portfolio IDs returned by `get_client_profile`\n\n. The agent cannot fabricate or substitute a different portfolio ID.\n\nThis policy prevents an attacker from using prompt injection to steer the agent to trade against a different client’s portfolio. The attacker can convince the LLM to use a fabricated ID, but the policy verifies the value against what the CRM system actually returned.\n\nget_client_profile returned |\nexecute_trade portfolio_id |\nExpected result |\n| port-8821 | port-8821 | ALLOW |\n| port-8821 | port-3347 | DENY |\n\n### Policy 3: Data freshness\n\nA `get_market_price`\n\ncall must have completed within the last 30 seconds before `execute_trade`\n\nis authorized. The agent cannot act on stale quotes.\n\nIn volatile markets, even a 60-second-old quote can represent significant price drift. This policy forces the agent to refresh its market data before every trade, ensuring that decisions are based on current information.\n\nTime since get_market_price |\nAction |\nExpected result |\n| 4 seconds ago | BUY Stock A | ALLOW |\n| 2 minutes ago | BUY Stock A | DENY |\n| Never called | BUY Stock A | DENY |\n\n### Policy 4: Cumulative budget cap per trajectory\n\nTotal trade value in a single policy session (or trajectory) cannot exceed $60,000. This contains blast radius from runaway agents or successful attacks.\n\nA compromised agent executing dozens of small trades that individually look fine can still accumulate catastrophic exposure. After $60,000, all trades are denied until a new trajectory begins.\n\nPrior cumulative trades |\nCurrent trade amount |\nTotal |\nExpected result |\n| $0 | $15,000 | $15,000 | Allow |\n| $15,000 | $22,000 | $37,000 | Allow |\n| $37,000 | $30,000 | $67,000 | DENY |\n\n### Policy 5: Human approval for large trades (one-time consumption)\n\nAny trade exceeding $25,000 requires the advisor’s explicit approval. Each approval is consumed by a single trade. A second large trade requires a fresh approval.\n\nThis prevents the agent from interpreting a single approval as blanket permission for multiple large trades. Each approval covers exactly one execution.\n\nTrade amount |\nApproval in trajectory |\nExpected result |\n| $15,000 | None | Allow (below threshold) |\n| $30,000 | None | DENY |\n| $30,000 | Approved (unconsumed) | ALLOW |\n| $30,000 (second trade) | Only prior approval (consumed) | DENY |\n\n### Policy 6: Mutual exclusion\n\nThe agent cannot buy and then sell the same security within the same trajectory if it sells for a loss.\n\nIf the agent sold AAPL two minutes ago and now tries to buy AAPL, the request is denied. The contradiction itself is the signal that something has gone wrong and the session should be reviewed.\n\nPrior action |\nCurrent action |\nTime gap |\nExpected result |\n| SELL Stock A | BUY Stock A | 2 min | DENY |\n| SELL Stock A | BUY Stock A | 7 min | ALLOW |\n| SELL Stock A | BUY Stock B | 2 min | ALLOW (different security) |\n\n### Policy 7: Progressive trust decay\n\nAfter 15 minutes without advisor interaction, the agent loses access to write operations (`execute_trade`\n\n, `rebalance_portfolio`\n\n). The advisor can re-engage at any time to restore full access.\n\nIf the advisor walks away, the agent naturally converges toward read-only behavior. This ensures that extended autonomous operation does not accumulate unchecked risk.\n\nTime since last advisor interaction |\nAction attempted |\nExpected result |\n| 3 minutes | execute_trade | ALLOW |\n| 20 minutes | execute_trade | DENY |\n| 20 minutes | get_market_price | ALLOW (read-only) |\n\n## Cost considerations\n\nYou only pay for the authorization requests performed during agent execution. Each time an agent calls a tool through AgentCore Gateway, Policy checks the action against your rules to determine whether it is allowed or denied. Your first 100 temporal policies per policy engine are included in the existing per-authorization-request price (see the [AgentCore pricing page](/bedrock/agentcore/pricing/) for details).\n\n## Clean up\n\nTo avoid ongoing charges, remove the resources you created in this walkthrough. Delete the resources in order: first delete the temporal policies from the policy engine, then detach the policy engine from the gateway, and then delete the policy engine itself. A policy engine cannot be deleted while it still contains policies or remains attached to a gateway. If you created the gateway, its MCP target solely for this walkthrough, delete those as well. Note that deleting or changing policies invalidates any active policy sessions, so perform cleanup only after your test sessions are complete.\n\nList and delete the policies on the policy engine. Repeat the delete-policy command for each of the seven policies:\n\nDetach the policy engine from the gateway by updating the gateway without a policy engine configuration:\n\nDelete the policy engine:\n\n(Optional) Delete the gateway target and gateway if you created them for this walkthrough:\n\n## Conclusion\n\nIn this post, you learned how temporal policies bring stateful, trajectory-aware authorization to agentic AI systems. You applied seven policy patterns to a hypothetical private banking portfolio agent. These patterns covered workflow sequencing, output-to-input integrity, data freshness, cumulative budget caps, human-in-the-loop approvals, mutual exclusion, and progressive trust decay. These patterns generalize across domains where agents interact with sensitive tools at runtime. Because enforcement happens at the AgentCore Gateway perimeter, outside the agent’s own reasoning loop, these protections remain tamper-proof regardless of model behavior. This gives you a declarative, auditable way to enforce operational boundaries without constraining the flexibility that makes agents valuable. To get started, review the [AgentCore documentation](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy-create-policies.html).", "url": "https://wpnews.pro/news/securing-ai-agents-with-temporal-policies-in-amazon-bedrock-agentcore", "canonical_source": "https://aws.amazon.com/blogs/machine-learning/securing-ai-agents-with-temporal-policies-in-amazon-bedrock-agentcore/", "published_at": "2026-08-06 18:57:55+00:00", "updated_at": "2026-08-09 11:47:38.547518+00:00", "lang": "en", "topics": ["ai-policy", "ai-agents", "ai-safety"], "entities": ["Amazon Web Services", "Amazon Bedrock AgentCore", "AgentCore Gateway"], "alternates": {"html": "https://wpnews.pro/news/securing-ai-agents-with-temporal-policies-in-amazon-bedrock-agentcore", "markdown": "https://wpnews.pro/news/securing-ai-agents-with-temporal-policies-in-amazon-bedrock-agentcore.md", "text": "https://wpnews.pro/news/securing-ai-agents-with-temporal-policies-in-amazon-bedrock-agentcore.txt", "jsonld": "https://wpnews.pro/news/securing-ai-agents-with-temporal-policies-in-amazon-bedrock-agentcore.jsonld"}}