Source: AWS Open Source Blog — 2026-08-06

Summary

AWS open-sourced Dogwood (Apache 2.0), a governance language for AI agents that extends its existing Cedar authorization language with temporal conditions — letting policies reason about sequences of past tool calls, not just a single action in isolation. Fully backward-compatible with Cedar and integrated into Amazon Bedrock AgentCore Policy, Dogwood enforces rules like "only allow this transfer if a human approved it within the last hour" or "block this action if the agent has already done it three times in the last hour" — evaluated at the gateway, outside the agent's own reasoning, so the agent can't argue its way around the policy.

Key Takeaways

• Dogwood implements a bounded, past-only fragment of Metric First-Order Temporal Logic on top of Cedar, and compiles ("lowers") down to plain Cedar policies at build time — every existing Cedar policy keeps working unmodified.
• Three temporal operators do the real work: formerly within <window> (did X happen at least once in the window), previous within <window> (did X happen at the immediately preceding step), and <left> since within <window> <right> (has a condition held continuously since some triggering event).
• count and sum aggregations let a policy enforce spend limits and rate limits directly — e.g., summing transfer amounts within a time window and denying anything that would push the running total over a threshold.
• Enforcement happens at the Bedrock AgentCore gateway layer, entirely outside the agent's own reasoning loop — the agent doesn't see the policy logic and has no path to reason around it.
• AWS is explicit that the reference interpreter is not production-ready: it doesn't validate event timestamps or authenticate events, keeps an unbounded in-memory trace with no crash durability, and its net feature performs no host/IP validation on outbound requests.

Reel Script

Hook: Most AI agent security today only checks one thing at a time: is this single action allowed, right now? AWS just open-sourced a policy language built to ask a harder question — has this agent done something suspicious in the last hour that should block what it's trying to do right now?

Core Concept: Think about a normal authorization rule: "this agent is allowed to transfer money." That's a snapshot check — it looks at one moment and says yes or no. The problem is a lot of real risk isn't about one action, it's about a pattern of actions over time — an agent that's tried the same risky move five times in the last ten minutes, or a transfer that's only supposed to go through if a human explicitly approved it sometime in the past hour. Cedar, AWS's existing policy language, is great at the snapshot check but has no concept of "an hour ago." Dogwood adds that missing time dimension on top of Cedar without breaking anything that already exists — your old policies keep working exactly as before, and the new temporal rules compile down into that same familiar format underneath. Crucially, this check doesn't happen inside the agent's own decision-making — it happens at the gateway, the choke point between the agent and the tools it's trying to call, so the agent literally cannot reason its way around a rule it can't see.

Hands-On: Here's a real policy from the project, only slightly simplified: a rule that permits a transfer under $1,000 but only if there's an Approve event from the matching approver "formerly within 1h" — meaning somewhere in the last hour, a human explicitly approved it. You can also build a straight rate check: count how many Transfer actions happened "formerly within 1h" and deny the request the moment that count hits three. The mechanism worth diagramming is the pipeline: a Dogwood policy file gets compiled down to a standard Cedar policy with the temporal condition packed into a context slot, a temporal engine fills that slot in at runtime by replaying the agent's recent event trace, and the gateway returns a plain allow-or-deny — the agent just sees its request get rejected, with zero visibility into why. AWS even ships a replay command that runs a saved trace of events through a policy and prints the allow/deny verdict at every point in time, which is exactly how you'd audit this after the fact.

Takeaway: If your agent security today only checks single actions, you're leaving an entire category of pattern-based abuse unguarded — a runaway loop, a rapid-fire retry, an action taken without the approval it actually needed. Dogwood is explicitly marked not production-ready, but the pattern it introduces — enforce time-windowed policy at the gateway, outside the agent's reach — is worth adopting even if you build your own version of it.

Discussion