Quick answer
An AgentCore temporal policy sees only the events in its policy session. Your client must generate a non-empty ID and send it as x-amzn-bedrock-agentcore-policy-session-id from the first related Gateway request onward.
Define the session as the smallest coherent unit whose actions need shared authorization history: one transaction, one approval-backed operation, or one bounded workflow. Do not treat the session ID as a global user identifier, an unlimited conversation store, or an account-wide rate-limit key.
Current AWS documentation limits each temporal condition to a maximum 24-hour window. A shorter rule window is often safer and easier to reason about.
The session contract
Record these fields before implementation:
| Field | Decision |
|---|---|
| Owner | Component responsible for generating the ID |
| Start | First request that establishes relevant history |
| End | Completed, cancelled, expired, or failed workflow |
| Identity | Principal propagated across every controlled hop |
| Scope | Actions and resources allowed to share history |
| Retry | Whether a retry reuses the same workflow session |
| Conflict | How the client recovers from invalidation or HTTP 409 |
| Retention | Shortest temporal window required by each policy |
The string alone does not define the session. AWS combines identity with the supplied ID, preventing two different identities that use the same text from sharing one trajectory.
Header behavior: follow current documentation
AWS’s August 6 launch blog and the current developer guide differ on omitted-header behavior. The current developer guide is the operational source of truth: Gateway does not generate the temporal policy session ID on the caller’s behalf. With a temporal policy on the engine, missing or empty session values fail validation.
Generate the ID before the first action. Send it consistently through retries and supported multi-hop calls only while they belong to the same unit of work.
Window and concurrency boundaries
AWS documents a maximum 24-hour window per temporal condition. This is a ceiling, not a recommended default. If a quote is safe for 30 seconds, use 30 seconds. If an approval is valid for one action during an hour, encode both the time and consumption rule.
Issue a dependent request after the predecessor’s response completes. Session history records the response after completion; overlapping the calls can leave the dependent authorization without the event it needs.
Keep one session narrow enough that serialized authorization does not become an application bottleneck. If separate tasks do not require shared history, give them separate session IDs.
Identity and multi-hop propagation
Temporal enforcement depends on the Workload Access Token reaching each controlled hop. AWS says AgentCore Gateway and Runtime can propagate it automatically within the same AWS account and Region. A third-party gateway, Kubernetes service, or other non-AgentCore component must forward the token through custom logic.
Current documentation also says cross-account and cross-Region propagation is not supported for this control surface. Model the topology before assuming a downstream tool call shares the original trajectory.
Policy-change invalidation
Adding or updating a temporal policy invalidates the policy engine’s active temporal sessions. The next request that reuses an invalidated session can fail with HTTP 409 ConflictException.
Safe deployment procedure:
- announce a policy-version change to workflow owners;
- stop admitting new work on the old policy version;
- let safe in-flight work finish or cancel it explicitly;
- deploy and validate the new policy set;
- create new session IDs with empty history;
- retry only idempotent requests or follow the tool’s recovery contract.
Never convert a conflict into a blind replay of a sensitive action.
Frequently asked questions
Which header carries an AgentCore policy session ID?
Send x-amzn-bedrock-agentcore-policy-session-id on every related Gateway request, starting with the first request in the policy session.
Does AgentCore generate a missing temporal policy session ID?
Current AWS developer documentation says no. If a temporal policy exists, an omitted or empty session ID fails validation.
Does the same session ID merge different users’ histories?
No. AWS scopes a policy session by identity as well as session ID, so distinct identities do not share one trajectory merely because the ID text matches.
What happens when a temporal policy changes?
Adding or updating a temporal policy invalidates active temporal policy sessions. Reusing an invalidated session can return HTTP 409, so clients need a new-session recovery path.
Related guides
- AgentCore temporal policies implementation guide
- Temporal versus stateless policy
- Tool-order and freshness policy
- Temporal policy planner
Official sources
Source check: August 8, 2026. Recheck the current session, identity, topology, quota, and conflict documentation before rollout.