AI security news · · 7 min read
AWS AgentCore temporal policies make agent history part of authorization
AWS now describes stateful gateway checks for tool sequences, cumulative exposure, and human approval. We map the lesson to GrantTap's local boundary without claiming feature parity.
An agent may make a series of individually reasonable tool calls whose combined effect is unsafe. A read from an untrusted source can be followed by an unexpected network transfer. Several small operations can exceed a budget that no single operation breaches. On August 6, 2026, AWS published a detailed explanation of temporal policies for Amazon Bedrock AgentCore. The important change is that a request routed through AgentCore Gateway can be judged against earlier events in the same trajectory rather than against its arguments alone.
This is news about an AWS gateway, not a new feature announcement for GrantTap. GrantTap's current Project Governance applies allow, ask, and deny rules for supported local coding-agent capabilities, with coverage reported by each computer. It does not advertise AWS-style trajectory state, cumulative trading limits, or a universal gateway for every provider-native action. The AWS design still provides a sharp question for any local controller: does the decision point know enough history to justify this exact action, and can the agent bypass that point? The answer depends on the route, not on the word “policy” in a menu.
What AWS published
AWS describes temporal policies as stateful authorization for requests reaching AgentCore Gateway targets. The current request is evaluated with prior events in a bounded agent trajectory. The article gives examples for ordering calls, checking that a later input matches an earlier tool output, requiring fresh data, limiting cumulative exposure, consuming one approval for one privileged action, and reducing write access after a period without human engagement. These examples appear in a hypothetical banking workflow; they should not be mistaken for measured outcomes from a real financial deployment.
The post also describes the enforcement point precisely. Policy runs at the AgentCore Gateway perimeter, outside the agent's own code, for traffic routed through that gateway. It returns allow or deny and logs decision context. A session is associated with a principal and session identifier, and the article describes a bounded look-back period. These details matter because starting a fresh session or taking a route outside the gateway changes what the policy can observe. The official AgentCore documentation is the source for configuration and current service limits.
Why a single tool check may be insufficient
Imagine a coding agent allowed to read an internal document and allowed to call an external HTTP client. A simple allow rule on each tool does not answer whether sending text from that document to the destination is appropriate. A history-aware policy could deny a protected sequence if both actions cross the same enforcing boundary and the relevant data lineage is represented. That conditional is crucial. A gateway cannot evaluate an invisible local shell command by wishing it had happened through the gateway.
Another example is repeated deployment. A human may approve one release operation, while an agent loops and attempts three. A one-time approval model needs to tie the approval to one action identity or consume it after use; otherwise a broad “approved” state may cover more than intended. AWS's article uses a high-value trade example to demonstrate that pattern. For coding work, the corresponding review question is whether an approval covers this exact command, repository, branch, destination, and time window. The GrantTap approval guide starts with that execution boundary.
What GrantTap governs today
GrantTap applies Project Governance to supported local integrations. A Project rule may allow, ask, or deny capability kinds including skills, MCP servers, shell and scripts, writes, deployment, and network activity; a named rule can target one capability. The phone authors a revision, the encrypted route delivers it to Project computers, and each computer reports the revision and whether a kind is enforced, observed only, unsupported, or unknown. A global provider deny remains stronger than a Project allow. The local hook evaluates a covered action before it runs.
This model addresses a different unit of control from AWS temporal policy. It helps the user decide and inspect what happens on their own coding computers, especially for primary Claude Code and Codex paths. It does not claim to reconstruct a complete multi-call causal history or authorize a later action by matching an earlier output. A provider-native route outside the hook remains outside GrantTap enforcement. A selected policy without a host acknowledgment remains an intended policy, not an applied one. Those explicit limits are valuable because users can test them rather than infer a guarantee from a phone screenshot.
Build an evidence chain before adding complexity
A useful history-aware rule first needs trustworthy events. Which process made the call? Which tool identity and version did it use? Did the tool run, fail, or only receive an approval? Did a file actually change? GrantTap's runtime distinguishes Invocation history from verified filesystem effects; it currently leaves unverified file changes unknown. That is the right foundation for later reasoning, even when it means the interface says less. A policy engine that consumes ambiguous event data may be more elaborate without being more reliable.
For one local Project, draw a timeline with four columns: proposed action, applicable rule, host decision, and observed outcome. Try a safe denied shell action and inspect the local refusal. Then run an allowed action and verify its actual result in the repository. Add the provider version and policy revision to the test record. If a later agent action depends on the first one, identify where that dependency can be checked today and where it cannot. This exercise is more informative than describing the whole product as “stateful governance.”
Consider the new failure modes
Stateful authorization introduces session boundaries. If an agent resumes under a new identifier, does it inherit past approvals or start with empty history? If policies change mid-task, what happens to active sessions? If a tool response arrives late, is it appended before the next request? AWS explicitly discusses session identity, look-back limits, and invalidation on policy changes. Developers adopting any trajectory model must document those rules, test concurrent requests, and avoid making old approvals silently durable.
Local coding work adds computer and checkout boundaries. A Task can continue on another machine in GrantTap, but a new execution may have different tools, policy coverage, credentials, and repository revision. A history from one host cannot simply be assumed to authorize a privileged action on another. The Task handoff guide describes the bounded facts that travel today. If a future policy ever uses history across that handoff, it will need a clearly defined identity, fresh host evidence, and explicit limits on which past events count.
How to read this news without overclaiming
AWS's examples show a promising way to constrain agents at a managed gateway when all relevant calls flow through it. They do not prove that every agent action everywhere is now safe, or that prompt injection is solved. GrantTap solves a narrower, everyday problem: seeing supported local coding work, making bounded decisions, and reporting host enforcement coverage without equating selected policy with confirmed use. These approaches can coexist because they cover different routes. The practical test is to trace one sensitive action from agent request to tool execution and ask exactly which process can still say no.
Readers can compare the local side in Project Mesh, the Project Governance guide, and usage evidence. For an AWS deployment, consult the current service documentation and reproduce the gateway example with harmless tools before extending it to sensitive data. For a GrantTap deployment, reproduce a denied local action on the actual provider and computer. In both cases, a visible denial with a specific boundary is stronger evidence than a broad policy description.
