AWS has open-sourced Dogwood, a policy language that extends its Cedar authorization language to govern sequences of agent tool calls. The release, announced in an InfoQ article on Aug 16, 2026, gives developers a way to enforce rules that depend on what an agent has already done, not just on the current request.
Dogwood is available under the Apache 2.0 license. It is a policy language built specifically for agent tool calls. The core difference from Cedar is that Dogwood rules can look backward at an agent's past actions. Cedar, by contrast, evaluates one request at a time. The same request yields the same answer regardless of history or order. That determinism is a strength for authorization, but it means Cedar cannot describe sequences of actions.
From Cedar to Dogwood
Cedar is the language behind AgentCore Policy, an AWS service for agent authorization that launched at re:Invent last year (2025). 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 touches enforcement.
AWS contributed Cedar to the Cloud Native Computing Foundation (CNCF) as a sandbox project in late 2025. Sandbox projects are early-stage open-source efforts. Cedar's deterministic evaluation and automated reasoning capabilities made it a strong base. But agents compose actions into workflows, and constraints often apply to sequences. Approval before acting, running totals, and stopping external contact after confidential data appears are all sequence-level rules.
Dogwood adds a second clause type to address this. It introduces a temporal condition inside a "when temporal" clause. That temporal condition can read the agent's event history. Events correspond to tool call requests and outcomes, carrying input arguments and the requesting principal.
The action schema comes from the agent's MCP tool manifest, with one action per tool. Dogwood generates the schema directly from that manifest. The temporal condition is translated into a Cedar context field, and the interpreter fills it from event history before Cedar makes its decision.
Four Operators for Temporal Logic
Dogwood provides four operators: formerly, count_within, count_distinct_within, and sum_within. These are not language primitives. They are standard-library macros over a core Metric First-Order Temporal Logic subset. The bind operator names an aggregate so it can be compared with the current request.
The operators let policies express things like rate limits. Consider a policy that caps spending at $5,000. An agent issues three concurrent $2,000 transfers. If the policy sums responses, it sees nothing in flight because none of the transfers has settled. All three pass, and the total reaches $6,000, breaking the $5,000 cap. If the policy sums requests instead, the third transfer is denied.
One word separates the two policies. Responses versus requests. That single change determines whether the cap holds under concurrency.
The article notes that asynchrony is not incidental. Agents issue parallel tool calls, and multi-agent interleaving compounds the problem. A policy that reads correctly in sequence can fail under concurrency.
The Cost of Temporal Power
Temporal evaluation is not free. It requires stateful tracking of events, and evaluation time can depend on the length of the event log. That is a meaningful cost for systems that process many tool calls.
There is also a loss in formal analysis. Temporal conditions do not support Cedar's automated reasoning analysis tools. Policy sets that use them lose the ability to be formally analyzed. AWS built a separate language rather than extending Cedar precisely because of this automated reasoning loss.
Stay ahead of the AI curve
The most important updates, news, and content — delivered weekly.
No spam. Unsubscribe anytime.
Existing Cedar policies still work in Dogwood. Any valid Cedar policy is a valid Dogwood policy. Deny-by-default remains in place, and forbid overrides permit. The language is designed to be a superset, not a replacement.
The Apache 2.0 license is not an invitation to deploy. AWS says the reference interpreter is for exploring and testing, not production. The repository warns that timestamps must be trusted, events must be authenticated, field and action names must be consistent, traces need durable storage, decisions need logging, and one tenant's history must never reach another.
A retention policy is also needed. Tool-call histories hold sensitive data, and keeping them indefinitely is a risk. Building a trustworthy event log is essential for Dogwood policies to be meaningful.
A Complementary Release
Dogwood's release came the same week as the MCP 2026-07-28 specification. That spec introduced required method and tool-name headers, which make agent traffic legible to HTTP infrastructure. Gateways and proxies can now see which tool an agent is calling.
The headers and Dogwood solve adjacent halves of the agent governance problem. Headers let a gateway see what tool an agent calls. Dogwood expresses what sequence of calls can add up to. Together, they give infrastructure visibility and policy control over agent behavior.
The release was co-authored by Marc Brooker, VP and distinguished engineer at AWS who led the Aurora DSQL launch, along with Joseph Tassarotti of the AWS Automated Reasoning Group and Jean-Baptiste Tristan of the AWS Agentic AI team. The InfoQ article was written by Steef-Jan Wiggers.
Roadmap and Contributions
AWS has a roadmap for Dogwood. Absolute-time windows for wall-clock boundaries are planned. Liveness properties, which express what must eventually happen, are also on the list. Orchestration policies for multi-agent systems, covering handoffs and locks, are planned as well.
AWS is not accepting contributions yet. The plan is to gather feedback first and open contributions as the language stabilizes. That gives the team time to see how Dogwood performs in real deployments before inviting outside changes.
The release marks a step toward making agent behavior governable. Cedar handled single requests. Dogwood handles the sequences that agents actually produce. The trade-offs are clear: temporal power costs evaluation time and formal analysis, but it enables policies that Cedar simply cannot express.
The example of the three concurrent transfers shows the stakes. A $2,000 transfer is small, but the pattern scales. The $5,000 cap is arbitrary, but the principle is not. When agents act in parallel, policies must account for what is in flight, not just what has settled.
Dogwood's approach is to make the event history a first-class input to policy decisions. That is a shift from the stateless evaluation model of Cedar. It requires infrastructure to track, authenticate, and store events. It requires policies to be written with concurrency in mind. And it requires operators to trust the logs their policies depend on.
The language is young. The reference interpreter is not production-ready. Contributions are not yet open. But the direction is set. AWS has identified a gap in agent governance, and Dogwood is its answer.