By AWS released Dogwood on August 6 — an open-source policy language that extends Cedar to govern sequences of AI agent tool calls within a session. It ships alongside rate limiting support for AgentCore’s gateway and is available under Apache 2.0 on GitHub. For teams running agents on Amazon Bedrock AgentCore, this is worth understanding now.
The problem Dogwood solves is specific. Cedar — the policy language already powering AgentCore Policy — evaluates one tool call at a time: does this principal have permission for this action on this resource? That model works for APIs and static systems. It breaks for agents. An agent can chain individually permitted actions into behavior you never intended to authorize. Each step passes. The overall sequence does not. Dogwood adds a session-aware layer: it inspects what the agent has already done in the current session before deciding whether to allow the next call.
What Dogwood Adds to Cedar
Dogwood introduces a when temporal { } block that queries the session event log — a structured record of prior tool calls, their inputs, and outputs. The temporal operators are:
- formerly within [window] — Was this action taken in the last N seconds/minutes/hours?
- sum_within — What is the running total of a field across session events?
- count_within — How many times has an action occurred in a window?
- count_distinct_within — How many distinct values appeared across events?
Migration cost is zero. Any valid Cedar policy is a valid Dogwood policy. Teams already using AgentCore Policy can add temporal rules incrementally without touching existing policies.
Here is the canonical example from the AWS announcement — a policy that prevents an agent from selling shares without a recorded human approval in the last hour:
permit (principal, action == AgentCore::Action::"SellShares", resource)
when temporal {
formerly within 1h AgentCore::Action::"ApproveSale"::response{
input.stock: context.input.stock,
input.shares: context.input.shares,
output.approved: true
}
};The policy checks that an ApproveSale response appeared in the session log with a matching stock ticker, share count, and approved: true — before permitting the sale. This is the human approval gate pattern, and it cannot be bypassed through the agent’s system prompt because the check runs at the gateway layer before the request reaches the agent.
A transfer budget policy looks like this:
forbid (principal, action == AgentCore::Action::"Transfer", resource)
when temporal {
sum_within(a, 1h, AgentCore::Action::"Transfer"::request{input.amount: a}) > 5000
};Block any transfer once the session’s cumulative total exceeds $5,000 in the past hour. The agent sees a rejection — not a budget figure it could be prompted to ignore.
Rate Limiting at the Gateway
Alongside Dogwood, AWS enabled three-dimensional rate limiting on the AgentCore gateway: request count, token volume, and connection duration. Each dimension catches a different failure mode. Retry loops spike request count. Reasoning-heavy tasks burn tokens. Long sessions hold connections open past what is reasonable.
Teams can cap all three, per user or per group, scoped by OAuth or IAM identity. Limits take effect immediately with no code changes in the agent. The granularity matters: a developer account can have different limits than a production service account, and a code-search tool can have tighter constraints than a documentation-lookup tool. This is cost management and security combined into the same configuration.
Why Gateway Enforcement Is the Right Model
The alternative — embedding authorization logic inside the agent via system prompt or application code — does not hold up. System prompts are suggestions that sufficiently clever input can override. Application code means every team reimplements the same rules differently. Infrastructure-layer enforcement is deterministic and consistent across every agent behind the gateway, regardless of how the agent is prompted.
Temporal policies run outside the agent’s own code. The agent cannot reason around them, no matter how it is prompted. That is the entire argument for why Dogwood-style governance belongs at the infrastructure layer rather than the application layer — and it is a sound one. The New Stack’s analysis frames it well: your agent’s next tool call may be individually valid but contextually wrong. Dogwood is the first open policy language specifically designed to catch that gap.
Where Dogwood Fits in 2026
Dogwood fills the policy enforcement slot in an agent governance stack that has been assembling across providers this year. Cloudflare gave agents an identity and a wallet in early August. Microsoft shipped Wassette for secure tool runtime. AWS now adds temporal authorization. The pattern is consistent: agent safety controls are moving out of the model and into the infrastructure — where they cannot be prompted away.
Dogwood is available on the dogwood-policy GitHub repository under Apache 2.0. The AWS Open Source team is not accepting direct contributions yet while the language specification stabilizes, but community feedback is welcome. Teams building on AgentCore can start with the AWS Machine Learning Blog implementation guide and the formal specification on the AWS Open Source Blog.
