Amazon Web Services has expanded Policy Authoring, the natural-language-to-code engine built into Amazon Bedrock AgentCore's Policy feature, so it can now generate rules that track what an agent has done over time — not just approve or reject a single tool call in isolation. The update lets a compliance document written for human staff be turned directly into Dogwood, the open-source policy language AWS uses to govern AI agents, without anyone hand-writing formal logic.

Policy in AgentCore already let teams restrict what an agent's tools could be called with, such as capping a refund amount. According to AWS ML, the new release extends that to trajectory and time: rate limits, mandatory prerequisite steps, cumulative caps across a session, and inline calls into Amazon Bedrock Guardrails for checking free-form text like dispute descriptions. All of it can now be authored by feeding a plain-English rules document into Policy Authoring instead of writing Dogwood by hand.

That matters because the gap between having a written compliance policy and having that policy enforced in code is exactly where a lot of agent deployments stall before reaching production.

From single calls to full sessions

The earlier version of Policy in AgentCore worked call by call: does this invocation's arguments satisfy the rule, yes or no. The expansion adds a temporal dimension, checked by the Dogwood monitor built into the AgentCore Gateway. A bank's customer-service agent — the example AWS uses throughout the post — might need funds transfers to happen only within 15 minutes of a successful identity check, no more than three refunds against the same account in an hour, or a running total moved between accounts that stays under $50,000 across 12 hours. None of those can be decided from a single call; they require reading the session's history, which is what the new monitor does.

How the translation actually works

Policy Authoring runs a four-stage pipeline: it decomposes a document into atomic rules, since a single sentence often bundles two independent conditions; routes each rule to check whether it is expressible in Dogwood at all; autoformalizes the survivors into policy code anchored against the agent's actual Model Context Protocol tool schema; and validates every candidate with the same open-source Dogwood command-line compiler that ships separately. A policy that fails validation goes back through translation with the compiler's error attached, for a capped number of retries.

Grounding against the MCP schema is the detail worth noting: generated policies reference the exact tool and argument names the agent calls, rather than plausible-sounding paraphrases, which keeps a rule from silently drifting away from what the agent's tools actually accept. Examples AWS walks through include:

What it deliberately won't translate

The more useful part of the release, for anyone planning to rely on it, is what AWS says the tool refuses to convert. Aspirational instructions like “act in the customer's best interest” get filtered out because there is no condition to check. Rules that ask for an action, such as redacting a Social Security number before storing it, get rejected too, since a policy engine can only permit or deny a call, not modify one. Dogwood also has no day-of-week or holiday calendar, so a rule like “no wire transfers on weekends” is not expressible as written. And enforcement is scoped to a single agent session, so a cap meant to apply across a customer's concurrent sessions cannot be recovered by rephrasing it.

Rather than silently producing a policy that looks correct and enforces the wrong thing, the pipeline routes those rules to a separate list with a reason attached, before translation is even attempted.

AiiN's takeaway

The part worth copying, even for teams not on AgentCore, is the discipline AWS documents around the ambiguity of natural language itself: state whether a rule counts attempts or completed outcomes, spell out the time window instead of writing “recently,” name which field a limit is keyed to — per caller or per account — and give the threshold's boundary, “more than” versus “at least.” Those checks are a reasonable pre-flight list for anyone drafting agent guardrails by hand, in any framework.

For teams already on Bedrock AgentCore, this closes a real gap: compliance teams keep owning the policy document in prose, engineers get an auditable, compiler-validated artifact instead of a hand-maintained if/else tree, and every generated rule ships next to the sentence it came from for review. The harder question, in our estimation, is whether Dogwood's session-scoped, permit/deny model covers what a specific agent needs to enforce — that still requires reading the limitations list before committing, not after.