Quick answer
Choose a stateless AgentCore policy when the current request contains everything needed to decide: who the caller is, which tool they want, which resource is involved, and whether the current inputs satisfy a rule.
Add a temporal policy when the answer depends on the same session’s prior events: whether an approval happened, a lookup returned the same value, a step completed in order, data is still fresh, or a bounded count or total remains under a threshold.
Most production designs need both. Stateless rules set the baseline authority; temporal rules narrow or extend that authority based on recorded trajectory evidence.
Decision matrix
| Question | Stateless policy | Temporal policy |
|---|---|---|
| Is this role allowed to call this tool? | Yes | Usually unnecessary |
| Is this resource in the caller’s permitted scope? | Yes | Only if history matters too |
| Did a matching approval occur earlier? | No prior-state access | Yes |
| Did a lookup return this exact identifier? | No prior-output match | Yes |
| Has the session total crossed a cap? | No accumulation | Yes, within the session |
| Is the current time inside business hours? | Time-based condition | Not session history by itself |
| Is a global account quota exceeded? | External/global control | Not solved by per-session history |
The policy type should follow the evidence required for the decision, not the complexity of the tool.
Combine the layers
A safe deployment typically evaluates four layers:
- Identity and baseline authority: principal, action, resource, tenant, role, and current input.
- Trajectory authorization: ordered prior events, matched fields, freshness, approval, or bounded aggregates.
- Tool-side validation: business invariants, idempotency, data validation, and transaction rules.
- Operational control: global quotas, monitoring, human escalation, rollback, and incident response.
Temporal policy belongs in layer two. It cannot compensate for an overbroad principal, a tool that accepts unsafe inputs, or a missing account-wide quota.
Where teams choose the wrong layer
Counting calls across all sessions
AWS documents that temporal history is session-scoped and the caller supplies the session ID. A count rule can limit one workflow trajectory, but starting a new session starts a new count. Use a separate durable limit for global user, tenant, or spend enforcement.
Treating wall-clock access as trajectory history
“Only allow this action during business hours” depends on the current time. “Allow this action only if a human approved it during the previous hour” depends on a recorded event. AWS treats these as distinct condition types.
Assuming policy runs the workflow
The policy engine returns an authorization decision. It does not invoke the prerequisite tool, repair an identifier, analyze a result, or choose the agent’s next step. The application still orchestrates execution and handles denials.
A selection workflow
For every sensitive action, write one sentence: “Allow this request when …”
- If the sentence only references the current request, start with stateless policy.
- If it references “after,” “before,” “since,” “already,” “within,” “total,” or “times,” identify the exact prior event and consider a temporal condition.
- If it references all activity across sessions or accounts, use a durable external control.
- If it references what the tool should do, keep that invariant in the tool or service.
Then test the combined rules with a minimal matrix: allowed baseline, denied principal, missing predecessor, wrong output-to-input match, stale predecessor, crossed threshold, new session, and changed policy.
Frequently asked questions
What is the difference between temporal and stateless AgentCore policies?
A stateless policy evaluates the current principal, action, resource, and context. A temporal policy can also match earlier events recorded in the same policy session.
Do temporal policies replace stateless policies?
No. Keep point-in-time permissions for baseline access and add temporal conditions only when session history changes whether the current action should be allowed.
Is a time-of-day rule a temporal policy?
Not necessarily. AWS distinguishes session-history temporal conditions from wall-clock time-based conditions that use the current system time.
Can temporal policy enforce a global rate limit?
A temporal count is scoped to one policy session. A caller can start a new session, so global user or account limits require a separate control.
Continue the implementation
- Full AgentCore temporal policies guide
- Session ID and trajectory-window design
- Tool-order and freshness patterns
- Temporal policy planner
Official sources
Source check: August 8, 2026. Validate current syntax, quotas, Regions, enforcement modes, identity propagation, and account boundaries before production use.