One request cannot describe a workflow

Cedar evaluates a principal, action, resource, and context. AWS uses it in AgentCore Policy because the decision is deterministic, auditable, and independent of the language model. A gateway can reject a tool call even if the model insists that it makes sense. AWS's account of the Cedar design calls this a safety envelope around each invocation.

The envelope is intentionally point in time. Identical requests receive identical decisions, and a request does not mutate the policy engine. That makes the rules easier to analyse, but it leaves out constraints that belong to a sequence.

Dogwood adds conditions over an event trace. formerly can require a matching event inside a time window. since can apply a restriction after a particular event. Windowed aggregations can count calls or total their values. The policy can distinguish "sell 20 shares" from "sell 20 shares after a granted approval for the same stock and amount within one 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 same pattern applies beyond trading. A support agent could lose permission to contact an external address after reading a customer record. A deployment agent could require a successful review event before promotion. A research agent could have a session budget across several paid calls, not merely a cap on each request.

History becomes security data

Once a policy looks backward, the result depends on earlier events being authentic, ordered correctly, stored durably, and tied to the right principal. A forged approval event can be as dangerous as a forged access token. If history is lost, legitimate work may stop. If tenants share a trace, one user's action may satisfy another user's rule.

The Dogwood repository lists those risks directly. The interpreter accepts supplied timestamps without validating them and does not authenticate events. Its in-memory temporal store has no size limit and vanishes on restart. It returns decisions without writing an audit log, while the default history is not isolated by principal. The repository also warns that provider scripts can make unrestricted outbound HTTP requests when the net feature is enabled, and that the Rhai runtime has no CPU or memory limits by default.

That list describes much of the work between a policy language and a dependable enforcement service. The reference interpreter can teach the language, validate policies, lower them to Cedar, and replay traces. It should not guard production tools in its current form.

Start by replaying failures

Dogwood's strongest immediate use is offline. Write one narrow rule and construct traces that try to break it. Its CLI provides three operations for this loop:

dogwood validate policy.dw --policy-schema schema.cedarschema
dogwood lower policy.dw --policy-schema schema.cedarschema --emit both
dogwood replay policy.dw --policy-schema schema.cedarschema --trace events.log

Include a valid sequence, a missing prerequisite, expired approval, mismatched arguments, repeated calls on the rate boundary, a restart, and events belonging to another principal. These cases test the rule and expose which surrounding components must be trusted.

The trace is also a more useful review artifact than a sentence such as "get approval before sending." That sentence does not specify whose approval counts, how recent it must be, which fields have to match, or whether a failed approval satisfies the condition. A replayable policy turns each ambiguity into an event and an expected verdict.

The separation resembles the one in our article about GSA's acq 3.1.0. Isolation limits where an agent can act. Authorization decides whether the current action is permitted. Temporal policy adds another question: is the action permitted after this exact history?

Do not confuse a language with a deployment

Dogwood currently includes a reference parser, validator, lowering path, interpreter, examples, and documentation under Apache 2.0. Its maintainers explicitly label the interpreter as non-production. Teams can evaluate the policy model without pretending the included runtime is ready to protect valuable tools.

For a prototype using api.ish.chat or another model API, place the policy check outside the model loop. Record tool requests and outcomes in a trusted trace, authorize before dispatch, and review a generated policy as code. Validation and hostile trace replay belong in that review. The model may suggest the next action. It must not write the authoritative history, approve itself, or waive its own rule.

RepoComplianceBench found that coding agents followed extra procedural instructions more reliably than stop conditions. Dogwood approaches a related problem from the enforcement side. A prohibition in a prompt is advice to a probabilistic system. An external decision at the tool boundary is enforceable only when the trace behind it is authentic, complete, and correctly isolated.