{"slug": "aws-dogwood-policy-language-for-ai-agent-authorization", "title": "AWS Dogwood: Policy Language for AI Agent Authorization", "summary": "AWS released Dogwood on August 6, an open-source policy language extending Cedar to govern sequences of AI agent tool calls within a session, available under Apache 2.0 on GitHub. Dogwood adds temporal operators such as formerly within, sum_within, count_within, and count_distinct_within to query session event logs, enabling policies like blocking share sales without human approval in the last hour or forbidding transfers exceeding $5,000 in an hour. AWS also enabled three-dimensional rate limiting on the AgentCore gateway, covering request count, token volume, and connection duration, with immediate effect and no code changes.", "body_md": "AWS released Dogwood on August 6 — an open-source policy language that extends [Cedar](https://docs.cedarpolicy.com/) 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](https://github.com/dogwood-policy/dogwood). For teams running agents on Amazon Bedrock AgentCore, this is worth understanding now.\n\nThe 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.\n\n## What Dogwood Adds to Cedar\n\nDogwood introduces a `when temporal { }`\n\nblock that queries the session event log — a structured record of prior tool calls, their inputs, and outputs. The temporal operators are:\n\n**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?\n\nMigration 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.\n\nHere 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:\n\n```\npermit (principal, action == AgentCore::Action::\"SellShares\", resource)\nwhen temporal {\n    formerly within 1h AgentCore::Action::\"ApproveSale\"::response{\n        input.stock: context.input.stock,\n        input.shares: context.input.shares,\n        output.approved: true\n    }\n};\n```\n\nThe policy checks that an `ApproveSale`\n\nresponse appeared in the session log with a matching stock ticker, share count, and `approved: true`\n\n— 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.\n\nA transfer budget policy looks like this:\n\n```\nforbid (principal, action == AgentCore::Action::\"Transfer\", resource)\nwhen temporal {\n    sum_within(a, 1h, AgentCore::Action::\"Transfer\"::request{input.amount: a}) > 5000\n};\n```\n\nBlock 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.\n\n## Rate Limiting at the Gateway\n\nAlongside 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.\n\nTeams 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.\n\n## Why Gateway Enforcement Is the Right Model\n\nThe 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.\n\nTemporal 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](https://thenewstack.io/aws-dogwood-agent-policies/) 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.\n\n## Where Dogwood Fits in 2026\n\nDogwood 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.\n\nDogwood is available on the [dogwood-policy GitHub repository](https://github.com/dogwood-policy/dogwood) 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](https://aws.amazon.com/blogs/machine-learning/control-agent-behaviors-and-cost-beyond-a-single-action-new-capabilities-in-amazon-bedrock-agentcore/) and the formal specification on the [AWS Open Source Blog](https://aws.amazon.com/blogs/opensource/introducing-dogwood-runtime-verification-for-ai-agents/).", "url": "https://wpnews.pro/news/aws-dogwood-policy-language-for-ai-agent-authorization", "canonical_source": "https://byteiota.com/aws-dogwood-agent-policy-language/", "published_at": "2026-08-10 13:11:43+00:00", "updated_at": "2026-08-10 13:35:20.212284+00:00", "lang": "en", "topics": ["ai-policy", "ai-agents", "ai-tools", "ai-infrastructure"], "entities": ["AWS", "Dogwood", "Cedar", "AgentCore", "Amazon Bedrock AgentCore", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/aws-dogwood-policy-language-for-ai-agent-authorization", "markdown": "https://wpnews.pro/news/aws-dogwood-policy-language-for-ai-agent-authorization.md", "text": "https://wpnews.pro/news/aws-dogwood-policy-language-for-ai-agent-authorization.txt", "jsonld": "https://wpnews.pro/news/aws-dogwood-policy-language-for-ai-agent-authorization.jsonld"}}