Dogwood: agent policies that remember prior tool calls

AWS open-sourced Dogwood, a policy language that decides whether an AI agent may call a tool based on what that agent already did earlier in the session. Regular authorization asks "is this agent allowed to sell shares?" Dogwood asks "is this agent allowed to sell these shares now, given that a human approved this exact trade eleven minutes ago?" That second question is the one that actually protects you, and until now most teams were answering it with hand-rolled if statements.

What actually happened

Per the AWS Open Source Blog post on Aug 6 by Marc Brooker, Joseph Tassarotti and Jean-Baptiste Tristan, Dogwood extends Cedar, AWS's existing authorization language, with temporal conditions. It ships under Apache 2.0, and it's backward compatible: any syntactically valid Cedar policy is a valid Dogwood policy, so there's no migration.

The theory underneath is Metric First-Order Temporal Logic, borrowed from runtime verification. The practical surface is a handful of operators — formerly, count_within, count_distinct_within, sum_within, and bind — that let a policy look backward over the session's event log. AWS's own example gates a trade on a matching approval:

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
    }
};

Note the argument matching. It isn't enough that an approval happened — the stock and share count have to match the sale being attempted. That closes the gap where an agent gets approval for one action and reuses it for another.

Two caveats AWS states plainly. Temporal evaluation needs stateful event tracking, and its time complexity scales with the length of the event log. And temporal conditions don't work with Cedar's automated reasoning tools, which is a real loss of verifiability that AWS calls a deliberate tradeoff. AWS also says the reference interpreter is for exploration and testing, not production. The production path is Bedrock AgentCore Policy, which now supports Dogwood.

Why temporal agent policies matter for your business

Every agent incident we've written about has the same shape. The single action was permitted. The sequence was insane.

Approval gates only work if they're enforced downstream. A confirmation dialog your agent can route around is decoration. Encoding the gate as a policy the tool call must satisfy is the difference between a control and a habit — the same argument we made about putting the approval gate out of the agent's reach and about YOLO mode.

Aggregate limits are where the money leaks. sum_within and count_within let you cap total transfer value or tool invocations across concurrent requests, not per request. Ten parallel agent branches each under the per-call limit is exactly how a spend cap fails in production.

You can steal the pattern without adopting the tool. Most small teams aren't running AgentCore, and the reference interpreter isn't production-ready anyway. The transferable part is the model: log every tool call and response as an event, then write the rules that gate the next call against that log. Prerequisite ordering, freshness windows, aggregate caps. We build that layer in plain code for clients who'll never touch Cedar, and it catches the same class of failure.

The useful reframe here is that agent safety isn't a prompt problem. It's an authorization problem with a clock.

Sources: AWS Open Source Blog, AWS Machine Learning Blog.