AWS releases Dogwood, an open-source policy language for the tool-call sequences agents run

AWS has released Dogwood, an open-source policy language and reference interpreter aimed at the space between an agent's individual tool calls, per a report in The New Stack. The operational read: if you have started letting agents open pull requests and push infrastructure changes on their own, the guardrail you have been reaching for is on the sequence of tool calls, not on any single call.

The New Stack framed the launch on August 6 as a fix for the class of failure where each call an agent makes is technically valid, but the order or combination of them is wrong. Rotating a credential and then pushing a build that still references the old one. Approving a merge and then running the release script from a stale branch. Neither call trips a permission check in isolation, and neither would trip a lint on the tool schema. The blast radius sits in the join.

What AWS actually shipped

Two pieces, according to the report. A policy language, and a reference interpreter that consumes policies written in it. Both are open source. The unit of enforcement is a whole sequence of tool calls. That is the specific gap policy-as-code frameworks aimed at IAM and OPA-style admission have never been built to cover.

Beyond those two pieces the release-specific detail thins out fast. Syntax, license, target runtimes and integrations with any named agent framework are not spelled out in the summary the pipeline was working from. Treat the announcement as a primitive for now, not a product. The interesting question for a platform team is whether Dogwood will sit alongside existing OPA and Cedar policies or displace something you would rather not have written yourself.

Why this matters if agents already touch your pipeline

The existing guardrails at the CI/CD boundary are mostly built for humans. Branch protection assumes a human is opening the PR. Deploy approvals assume a human clicked a button. Least-privilege on the deploy key assumes an operator who paused when a script started doing something odd. An agent will not pause. It will chain calls faster than a review window, and if each individual call passes its own check the aggregate is what lands in production.

Policy over sequences is where you get to encode the rules a reviewer would apply out of habit. Do not run a release cut against a branch that has not been rebased. Do not merge a PR whose CI signals came from a workflow that was edited in the same PR. Do not open a change against production if the last five actions were exploratory. None of those are single-tool concerns.

Where this lands in a rollout

A few operational notes for anyone thinking about picking it up.

• The interesting failure mode here is silent bypass, not policy violations you can see in the log. If an agent has more than one path to the same effect, only the path that goes through the interpreter is governed. Everything else is unmonitored. Any adoption plan starts with an audit of how the agent actually acts on your systems.
• Policy authored against sequences is heavier to reason about than per-call rules. Expect the first draft to be wrong. Roll out in report-only mode, log the sequences that would have been blocked, and only then move to enforce.
• The reference interpreter is a starting point. Production adoption depends on where the interpreter runs, how it fails, and whether a slow or unavailable policy check turns into a silent allow. Those are the questions your platform team will need answered before this becomes a load-bearing gate.

Broader context

Dogwood lands during a wider industry pivot toward treating agents as their own identities inside CI/CD systems, with their own principals and their own audit trail. Policy over tool-call sequences is the layer that pivot has been missing. Other projects in the space cover pieces of it. Model Context Protocol servers govern which tools an agent can see. IAM and OPA govern individual actions. Guardrail libraries scope free-form output. None of them, as shipped today, take a full transcript of tool invocations and answer whether the trajectory as a whole is allowed.

Whether Dogwood becomes the vocabulary the industry settles on, or joins the pile of policy languages platform teams are quietly relieved to have never adopted, is the question the next few months will answer.

The residual caveat is smaller and older. Any policy engine is only worth the coverage it actually has. If an agent can reach a shell escape or an unmonitored side channel, its behaviour outside the interpreter is unmonitored too. Dogwood does not close that hole. Nothing in the report suggests it claims to.