Quick answer
Use an AgentCore temporal policy to require a matching, recent, unconsumed human approval before a sensitive Gateway action. Use a bounded sum or count to contain cumulative activity inside the same policy session.
Combine the controls: a single action can be below its individual approval threshold yet still push total session exposure above the cap. Neither control is global, and neither replaces the downstream service’s transaction checks.
The dollar thresholds in AWS’s banking example are illustrative. Set amounts, windows, roles, and required fields from your own risk and compliance decisions.
Design a one-time approval
An approval record should bind to the action it authorizes, not merely appear somewhere in history. Capture at least:
- approving principal and role;
- target action and resource;
- exact subject or transaction ID;
- relevant amount, scope, and currency;
- approval result;
- issue time and expiry;
- unique approval ID;
- whether a successful execution already consumed it.
The policy should reject missing, stale, mismatched, denied, or already consumed approvals. The application should present enough context for a human to make a real decision and should log who approved what.
Design a cumulative cap
Dogwood supports sum and count over matching events within a time window. Decide whether the cap should count attempted requests, completed responses, reserved capacity, or settled value. Those are different business rules.
Be explicit about whether the current invocation is included. AWS’s current documentation notes that a self-referential temporal condition includes the request being authorized. Test just below, exactly at, and just above the threshold.
Also decide what happens after a downstream failure. If the request was permitted but the transaction failed, should its amount remain reserved, be released, or require reconciliation? Policy history cannot infer settlement semantics unless the relevant events and fields exist.
Session limits are not global limits
Temporal history is scoped to a caller-supplied policy session. Starting a new session starts a new count and sum. Therefore:
- use temporal caps to contain one workflow or transaction trajectory;
- use a durable service-side ledger for user, tenant, daily, or account-wide exposure;
- prevent callers from choosing session boundaries that bypass your intended control;
- reconcile policy events with authoritative transaction state.
A per-session denial is useful blast-radius containment, not a complete financial-control system.
Approval test matrix
| Scenario | Expected result |
|---|---|
| Below threshold, within session cap | Follow baseline policy |
| Above threshold, no approval | Deny |
| Approval for different subject | Deny |
| Approval with mismatched amount or scope | Deny |
| Matching unexpired approval | Allow if every other rule permits |
| Second action reusing consumed approval | Deny |
| Valid approval but cumulative cap exceeded | Deny |
| New session with no approval history | Deny |
Add retry, timeout, partial failure, policy invalidation, and identity-change cases before enforcement.
Production safeguards
Run new rules in LOG_ONLY, review false allows and false denials, then promote them deliberately. Keep the approval interface outside the agent’s uncontrolled reasoning loop, use least privilege for approvers, and make sensitive execution idempotent.
When policy changes invalidate active sessions, do not silently turn an old approval into a new one. Start a new policy session and require whatever evidence the updated policy demands.
Use the temporal policy planner to record the session scope, approval binding, aggregation basis, thresholds, and test cases.
Frequently asked questions
Can one AgentCore approval authorize only one action?
Yes. A temporal rule can require a matching approval and deny reuse after a later execution consumes it, provided the event schema and correlation fields are designed correctly.
Can AgentCore cap cumulative value in a session?
Yes. Dogwood supports bounded aggregations such as sum and count over matching events in the current policy session.
Is a per-session cap an account-wide budget limit?
No. A new session begins a new history, so account, tenant, or user-wide limits need a separate durable control outside the session.
Should approval and budget policy replace tool-side validation?
No. Keep transaction validation, idempotency, authorization, accounting, and global limits in the downstream service as well.
Related guides
- AgentCore temporal policies guide
- Trajectory session boundary design
- Tool order and data freshness
- Dogwood versus Cedar
Official sources
Source check: August 8, 2026. Verify the current event schema, identity scope, time window, quotas, enforcement mode, and downstream transaction contract before use.