The Pulse
AWS Releases Dogwood Local Engine for Agent Tool Calls
AWS released the Dogwood Local Engine, an Apache 2.0 library that evaluates AI agents’ tool calls against policies involving earlier actions. The engine returns allow-or-deny decisions, but the agent harness must enforce them and protect th
AI.info Team · Written with AI ·
AWS’s new policy engine can tell an AI agent’s harness to block a tool call, but it cannot stop the call itself. The Dogwood Local Engine, released on September 30 under the Apache 2.0 license, evaluates actions against policies that account for what an agent has already done; a separate enforcement layer must intercept the call and obey the result.
That division places the security burden partly outside the engine. The harness must send it accurate records of relevant events, prevent the agent from tampering with its state and ensure a denied action never runs. AWS is offering developers a local policy evaluator, not a self-contained boundary around an agent.
Dogwood checks the steps before a tool call
Dogwood policies can express conditions based on the sequence, timing and outcomes of earlier actions. AWS’s example is a coding agent that may push changes to Git only if its most recent test run passed within the previous 15 minutes and no later test run failed. A failed test blocks the push; a passing run allows it only until that time window expires.
The engine records both request events, when an agent calls a tool, and response events, which capture what the tool returned. It issues verdicts for requests, using responses such as a test result to evaluate later actions. AWS says developers can update policies during a session without stopping the engine, though the history for a newly updated temporal rule starts with events received after that update.
“Its responsibility is solely to issue correct allow/deny verdicts based on the events it is shown and the set of policies.”
Jatin Arora, Joseph Tassarotti and Jean-Baptiste Tristan, AWS Open Source Blog
The harness remains the enforcement point
For the engine to work as intended, the harness must submit every relevant event, run a tool only after an allow verdict and report the tool’s response afterward. AWS says the harness also needs to keep its event interface accessible only to itself and use operating-system isolation or sandboxing where needed to stop tool calls from altering the engine’s state.
The project’s repository spells out the boundary further: the application integrating the library must authenticate event provenance, secure access to policy updates and state files, and maintain a separate audit log. The engine’s own durable records are periodically checkpointed and pruned; they preserve enough information to recover and make future decisions, but not a complete history for auditing.
Timekeeping is another dependency. The engine assigns event timestamps using the host system clock and ensures they increase monotonically, but the repository warns that clock skew or other changes can still affect policy outcomes. A policy can only account for events the harness actually sends it.
Durability adds work to every decision
To order concurrent events, the engine admits one submission at a time under a lock, timestamps it and appends it to a log. It synchronizes each append to disk before evaluating the policy. After a crash, the engine rebuilds its in-memory evaluation state from a saved snapshot and newer log entries; AWS says the log uses redb, an embedded Rust key-value store.
The disk write adds latency before a tool can proceed, and evaluation time varies with policy design. AWS tested simulated sessions lasting five minutes to 12 hours, producing 360 events an hour. With a 24-hour policy window, a decision took six milliseconds at the 12-hour point—300 times longer than with a 15-minute window. The company also found that, in its test with 100 policies, dividing Git operations into five separately scoped actions made push evaluations roughly five times faster than using one broad Git action.
Open source, with the integration work left to developers
Dogwood Local Engine is a Rust library that can be embedded in an agent harness or used in a demonstration local service. Its release extends Dogwood, the open-source policy language AWS introduced in August, beyond the managed AgentCore setting by making a local engine available for developers to integrate into their own systems.
The tradeoff is explicit: teams gain a way to evaluate sequence-aware rules locally, while remaining responsible for the controls that make those decisions meaningful. The engine can deny a Git push after a failed test only if the harness records that test result, submits the push request and blocks the tool when the verdict says no.