AWS has open-sourced Dogwood, a policy language designed to control sequences of agent tool calls rather than just individual actions. Built to extend Cedar, Dogwood is meant to let organizations express rules that depend on what an agent has already done, while keeping the policy decision outside the model itself.
What Dogwood adds to AWS AgentCore Policy
Dogwood arrives as part of AWS AgentCore Policy, which launched at re:Invent last year. According to AWS, AgentCore Policy sits outside the model as a deterministic control layer: the model proposes a tool call, the policy engine accepts or rejects it, and the model never performs enforcement.
Cedar is the language used for those decisions, and AWS contributed Cedar to the CNCF as a sandbox project in late 2025. Dogwood does not replace it. Instead, it adds a way to reason about sequences, which Cedar by itself cannot describe.
Why Cedar needed an extension
AWS describes Cedar as a request-by-request language. If you feed it the same request twice, you get the same answer, regardless of what happened before or how the policies were ordered. That predictability is useful for auditability and automated reasoning, but it also limits Cedar to fencing off single actions.
For agentic systems, that is often not enough. Teams frequently need policies that depend on the order of actions, such as requiring approval before acting, enforcing a running limit, or stopping external contact after sensitive data has been touched.
How Dogwood handles agent history
Dogwood adds a temporal clause type alongside Cedar’s ordinary conditions. A temporal condition can look at the agent’s event history, where events represent tool call requests and their outcomes, including input arguments and the requesting principal. The action schema is derived directly from the agent’s MCP tool manifest, with one action per tool.
Under the hood, AWS says temporal conditions are translated into a Cedar context field that the interpreter fills from event history before Cedar makes the decision. In other words, Cedar still makes the final policy call, but Dogwood gives it more context about what has already happened.
The four temporal operators AWS highlighted
AWS says Dogwood defines four common temporal shapes as standard-library macros over a core Metric First-Order Temporal Logic subset:
- formerly — whether something happened within a window
- count_within — how many times something happened
- count_distinct_within — how many different values appeared
- sum_within — a running total across events
A bind operator can name an aggregate so the current request can be compared against it.
A concurrency trap AWS wants teams to notice
One of the clearest examples in the announcement involves a policy meant to cap transfers at $5,000. AWS says a policy written against response events can be bypassed when multiple requests arrive concurrently, because nothing has settled yet. In the example, three simultaneous $2,000 transfers are all allowed past the cap when the policy sums responses, but the third transfer is denied when the policy sums requests instead.
The point is not just a wording difference. As AWS notes, agents can issue parallel tool calls, and multi-agent systems can interleave those calls in ways that break policies that look correct in a simple sequence.
Trade-offs: more power, less formal analysis
AWS is explicit about the cost of temporal evaluation. It requires stateful tracking of events, and evaluation time can grow with the length of the event log. More importantly, temporal conditions do not support the automated reasoning tools that Cedar provides.
That loss of analysis capability is part of why AWS chose to build a separate language rather than extend Cedar directly. The company says existing Cedar policies remain valid in Dogwood, so current policy sets do not need to be rewritten. Deny-by-default remains in place, and forbid still overrides permit.
Open source, but not production-ready out of the box
Dogwood ships under the Apache 2.0 license, but AWS cautions that the reference interpreter is for exploration and testing, not production authorization. The repository also calls out the operational requirements needed to make temporal policy evaluation trustworthy.
Those requirements include trusted timestamps, authenticated events, consistent field and action names, durable trace storage, decision logging, tenant isolation, and a retention policy for sensitive tool-call histories. AWS’s message is clear: the policy language only works if the event log behind it is reliable.
Why this matters for agent infrastructure
The release lands during a period of rapid standardization around agent traffic. AWS notes that the MCP 2026-07-28 specification made agent requests more visible to HTTP infrastructure through required method and tool-name headers. Those headers help a gateway identify what tool an agent is calling, while Dogwood describes what sequences of those calls are allowed to accumulate into.
That makes the two efforts complementary rather than redundant. One helps infrastructure see agent actions more clearly; the other helps policy systems decide whether those actions remain within bounds over time.
Roadmap and authorship
AWS says future Dogwood work includes absolute-time windows tied to wall-clock boundaries, liveness properties that express what must eventually happen, and orchestration policies for multi-agent systems, including handoffs and locks.
The release was co-authored by Marc Brooker, a vice president and distinguished engineer at AWS who led the Aurora DSQL launch, along with Joseph Tassarotti of the Automated Reasoning Group and Jean-Baptiste Tristan of AWS Agentic AI. AWS is not accepting contributions yet, saying it wants feedback first and will open contributions later as the language stabilizes.
Source: Original report
Was this helpful?
Explore more: AI Automation Services More AI & Automation Tech News
Last Modified: August 19, 2026 at 1:54 am
4 views
