Temporal Guardrails Move the Control Into the Event Log

Temporal guardrails change what an agent policy decides: not only whether this request is allowed, but whether it is allowed given everything the agent has already done. AWS's open-source Dogwood Local Engine documents its event handling and recovery model in enough operational detail to reason about the idea concretely. The language it enforces was introduced in the earlier Dogwood runtime verification post. The part of temporal guardrails worth an architect's attention is the boundary around it, because a stateful verdict is only as trustworthy as the history it was computed from.

This post is scoped to the open-source Local Engine and the language as AWS described it. It makes no claim about the managed AgentCore Policy integration.

Stateless Policy Decides on the Request. Temporal Guardrails Decide on the History.

Dogwood extends Cedar, and its temporal guardrails are built on that base. Any valid Cedar policy is a valid Dogwood policy, evaluation is deny-by-default, and a forbid overrides a permit. What Dogwood adds is a when temporal { ... } clause with operators such as formerly, count_within, count_distinct_within, sum_within and bind. With those, a policy can express prerequisites and ordering, rate limits, distinct-value limits and running totals.

That changes the shape of the decision. A stateless policy is a function of the request and the policy text. A temporal clause makes the verdict a function of the request, the policy text, and an event history the engine accumulated before the request arrived. In AI infrastructure architecture terms, the policy decision point stops being a pure function over a rule set. Once a rule can say "no more than five transfers in an hour" or "only after an approval event," the decision point also becomes a place where state lives, and state has an author, a lifecycle and a failure mode.

The control pattern is not new in kind. A token-budget limit at a gateway, as in the authority model in Nutanix Put MCP Behind a Gateway, already refuses a call because of what already happened. What temporal clauses do is make that "because of what already happened" expressible in the policy language itself rather than in gateway-specific counters.

Where the History Comes From

The Local Engine is a library embedded in a harness. The harness intercepts each tool call, submits a request event to the engine, runs the tool only if the verdict is allow, and then submits a response event. The engine issues verdicts only for request events; response events record outcomes. On arrival, the engine linearizes events under a lock, timestamps them, and appends them to a durable log that is synced to disk before evaluation. It keeps in-memory summaries per temporal clause, takes periodic snapshots, and rebuilds state by loading a snapshot and replaying later events. Policy updates are logged in the same sequence as events, and recovery yields either the complete pre-update or the complete post-update policy set.

AWS is explicit about who is responsible for what. The harness must provide event integrity. The event interface must be reachable only from the harness, and harness and engine state must not be manipulable by other processes or by the effects of tool calls. The library does not perform operating-system isolation.

Read that table the way you would read a shared-responsibility matrix. The two "not stated" rows are not criticisms; they are the questions your integration has to answer for itself.

Architectural guidance (not AWS's): treat the harness-to-engine event feed as an authenticated channel with one trusted submission path, because the engine will believe whatever it is told. A literal single-writer implementation is one way to get there; AWS's stated requirement is narrower, that the event interface be reachable only from the harness. An agent that can influence what the harness reports, or write to the same state through a tool side effect, is not being governed by the guardrail; it is authoring it. This is the same identity-isolation concern we raised in the agentic control plane problem and in the MCP security architecture analysis of the Agentic Authority Boundary: the component enforcing the rule must not share a trust domain with the thing the rule constrains. The runtime-control stage of the Governance & Runtime Control learning path frames where that boundary sits.

The Blind Window

Here is the mechanism that defines the whole problem with temporal guardrails. AWS documents that a new or modified temporal clause counts only events that arrive after the update. Its history starts at the update, not at the beginning of the log.

That is a reasonable design, and for temporal guardrails it is also a boundary you have to reason about. Whenever a clause is added or changed, there is a period in which it is evaluating a truncated view of the past. The agent's earlier behavior exists in the log, but the clause cannot see it.

The two inferences below are mine, drawn from the documented behavior. AWS does not state them.

ILLUSTRATION — CONSTRUCTED FOR THIS POST, NOT AN AWS EXAMPLE:

• Permissive error — An agent submits 40 transfers between 13:00 and 14:00. At 14:00 an operator adds a clause: forbid a transfer when five have already occurred in the trailing hour. Because the clause's history begins at 14:00, it counts none of those 40 at 14:01. Depending on whether the current request counts toward its own verdict, which the post does not state, it permits roughly the next five. A rule written to cap the burst is blind to the burst that motivated it.
• Restrictive error — At 09:00 an approval event is logged. At 14:00 an operator adds a clause: forbid release unless an approval occurred in the last 24 hours. The clause never saw the 09:00 approval, so it denies every release until a fresh approval arrives. Inference one: for a rolling window, the blind window is bounded by the clause's own window length, assuming the documented window semantics and the events' timestamps behave as described. Pre-update events stay outside the new clause's history until they would have aged out of the applicable window anyway. A one-hour clause stops being incomplete about an hour after the update; a 24-hour clause about a day after. Longer windows are not only costlier to evaluate, they stay unrepresentative for longer. This is a statement about when the clause matches the intended policy, not a guarantee about any specific verdict.

Inference two: the direction of the error depends on how the rule is written. A "forbid when the count is reached" rule errs permissive during the window. A "forbid unless a prior event is present" rule errs restrictive. Neither error direction can be assumed acceptable without an explicit transition procedure, and the same update process produces both.

This is where the evidence question sits. In AI Systems Need Evidence, Not Just Observability, component 02 of the AI Evidence Artifact Layer is the policy state snapshot: the constraint that was active when execution occurred, immutable and verifiable without access to the current policy configuration. The claim here is narrow. A snapshot of the policy text alone is not sufficient to reconstruct a temporal verdict. To explain why a particular request was allowed or denied, you also need the clause's start point and the event history inside its window. Nothing prevents a snapshot from carrying those. A snapshot combined with the event log and the clause-start boundary provides the essential inputs for reconstructing the decision, provided the exact policy version, the event ordering and timestamps, and the evaluation context are also preserved. But a record that stores only "policy version 14 was active" will not tell an auditor why the same request was allowed at 14:01 and denied at 15:01.

Windows Change Meaning When You Shorten Them

The August post is direct that evaluation of temporal guardrails is stateful and that cost can depend on event-log length. The Local Engine post puts a number on it, with a context that matters: each benchmark point is the median of 200 evaluations on one server-class host, using simulated sessions generating 360 events per hour. At a twelve-hour session length, the 24-hour window took about six milliseconds per decision, while the 15-minute window stayed flat. Those figures describe that one host under those conditions. They are not a production-latency commitment, and they say nothing about your harness, your event volume, your storage or your concurrency.

The same post notes that shortening a window is safe only if the shorter window still meets the requirement. That sentence deserves more weight than it gets. Shrinking a 24-hour clause to 15 minutes to recover latency on that single host is a change in what the control means, not a tuning step. A cumulative-spend ceiling over a day and a burst limit over a quarter hour are different controls that happen to share an operator.

Architectural guidance (not AWS's): record each window together with the risk it was sized against. "Twenty-four hours because the daily settlement cycle is the exposure" survives a performance review. "Twenty-four hours" does not, and it will be the first number someone proposes to cut when the latency graph looks bad. The blind window compounds this when the change modifies the clause: a window-length edit is a clause modification, so it resets that clause's history boundary as described above.

What to Test in Your Own Temporal Guardrails Integration

Diagnostic: "When a temporal clause changes, which events does it count, who wrote them, and what would you read to prove it?"

These four checks for temporal guardrails are architectural guidance. They are not an AWS procedure, and they do not assume Dogwood supports any particular remediation such as back-filling history into a new clause. If it does not, the mitigation is operational: schedule clause changes, and compensate during the window. Run them in a controlled test harness, not against a production log device, and capture evidence for each: the attempted action, the observed result, and the event-log state afterward.

01 — FEED INTEGRITY

Attempt to submit a forged event, and to alter engine or log state, from inside a tool call. The test passes only if the harness is the sole path in, tool side effects cannot reach the state, and the log is verifiably unchanged afterward. A forged event that merely fails to execute does not prove the log stayed intact.

02 — CLAUSE START POINT

Add and modify a clause against a log with known prior events. Confirm the clause ignores them, then confirm your change procedure records the start boundary and the compensating control used during the window.

03 — WINDOW SIZING

For every clause, write down the exposure the window length answers. Measure latency on your own harness and storage rather than importing the single-host benchmark figures.

04 — FAILURE MATRIX

The post does not state fail-open or fail-closed behavior, and the states differ. Exercise each in a test harness: engine unavailable before a verdict; log persistence failure before evaluation completes; failure after a durable append but before a verdict returns; failure after an allow but during tool execution. Define the expected response per state before an incident does.

Where This Stops

This analysis covers the open-source Local Engine and the language as the August post describes it. It does not extend to the AgentCore Policy integration, whose deployment topology the sources do not state, so nothing here should be read as a finding about the managed service.

It is also not a claim that Dogwood is unsafe. The blind window follows from a documented, defensible design choice, and the harness responsibilities are documented rather than hidden. Two limits from AWS's own description matter for how much weight your tests carry: temporal conditions do not currently support Cedar's automated reasoning tools, so you cannot lean on that analysis for them, and liveness properties and absolute wall-clock windows are listed as future work.

Architect's Verdict

Temporal guardrails are a genuine improvement in what an agent policy can express. Rate limits, prerequisites and running totals belong in the policy layer, not in ad hoc gateway counters.

Once temporal guardrails put the control in the log, three questions replace the old one. Who is allowed to write to it, which part of the past can a given clause actually see, and what proves the answer after the fact. AWS answers the first by assigning event integrity to the harness, and answers the second implicitly by starting each clause's history at its update. The third is left to you.

In operation, that makes a clause change a controlled transition: a named start boundary, a compensating control for the window, and a record an auditor can use. Window length belongs to the control, not to performance tuning.

A guardrail that remembers is only as sound as what it was allowed to remember, and from when.

Additional Resources

• AI Infrastructure Architecture — the pillar hub for AI infrastructure design decisions, including where runtime governance sits relative to compute, data and orchestration.
• Governance & Runtime Control — the learning-path stage covering enforcement points, authority boundaries and runtime control for agentic systems.
• MCP, Tool Use, and the New Attack Surface Nobody Is Mapping — the Agentic Authority Boundary and the identity-isolation controls that govern what a harness must keep separate from tool context.
• Agentic AI Has a Control Plane Problem — Because It Became the Control Plane — why the component enforcing policy cannot share a trust domain with the agent it constrains.
• AI Systems Need Evidence, Not Just Observability — the AI Evidence Artifact Layer and why a policy-state record has to be verifiable independently of current configuration.
• Nutanix Put MCP Behind a Gateway. The Real Problem Is Authority. — a gateway-level control that refuses calls based on prior consumption, the counter-based precursor to temporal clauses.
• Introducing the Dogwood Local Engine: Temporal Governance for Agent Actions — AWS Open Source Blog; the primary source for the harness model, event log, recovery and benchmark described here.
• Introducing Dogwood: Runtime Verification for AI Agents — AWS Open Source Blog; the language description, operators and stated limits.

Originally published at rack2cloud.com