The Dogwood local engine gives developer run 'agent harnesses,' the orchestration layer that calls tools and chains actions, a history aware allow/deny without an AWS account.
AWS open-sourced a piece of agent infrastructure that used to live behind a cloud account: the Dogwood local engine, a Rust-based, Apache-2.0 authorization library that lets any developer's laptop answer "is this allowed right now, given everything my agent has already done?" (The Register).
The "leash" framing belongs to AWS, not the source code. Strip the marketing and the underlying mechanism is concrete. The local engine linearizes every agent action under a lock, timestamps it, and persists it to a durable ordered log before evaluating the policy (README). Verdicts are history-retaining: when a policy asks whether some prior event happened in a given window, the engine reads the log. When the policy updates, the new version shares the same durable log, so temporal windows stay consistent across edits.
This is a meaningful shift. Most authorization libraries answer one-off questions: "Can this user delete this file?" Agent workloads need a different question. A coding agent that has already pulled credentials, opened a shell, and now wants to write to a production repo is a different request than a fresh tab, even if both call the same tool. Allow/deny that ignores history cannot reason about escalation. The local engine is built for that case, with policies whose conditions reference the accumulated event log rather than just the request in front of them.
The architectural choice is the story. Running it on a developer box means the clock, the log, the policy store, and the audit trail all stay in-house. No request leaves the network. A regulated team gets the same control surface AWS itself uses for its cloud products, on the same hardware where the agent is running, with no AWS account, billing relationship, or telemetry required (The Register). The downstream consequence is that a developer can ship a customer an agent whose governance rules the customer can read, audit, and modify without going through AWS as a middleman.
But the engine is deliberately small. Maintainer documentation is explicit: it produces verdicts but does not enforce them. It does not authenticate the truthfulness of the events it processes. Integrators supply the events, secure the policy controls, protect the clock, and maintain a separate audit log because the internal history is pruned (README). None of those jobs is new, but doing them correctly is the actual integration work most teams will have to do. The "leash" does not come with a collar.
The source material also notes that newly added policies start with empty histories while unchanged ones keep their accumulated state, and that policy updates share the ordered durable log with events, so the engine can reason about time-spanning conditions across edits (README). That sounds like a small detail until you build a policy that references behavior from before a redeploy.
GitGuardian's earlier write-up of the Dogwood language framed it as temporal authorization built on Cedar, AWS's existing policy language. The local engine is the runtime that was missing. Whether the wider open-source agent ecosystem adopts it, builds something compatible, or forks it, will be the next thing worth watching.