Agent safety becomes a policy engine: AgentCore now polices tool-call sequences, not just arguments

Amazon Web Services has expanded Policy in Amazon Bedrock AgentCore so that rules can constrain agent actions across time, covering rate limiting, prerequisites and sequential ordering of tool calls, and cumulative effects ^[2]. Those rules are written in Dogwood, which AWS describes as an open source governance language, and are applied to agent actions in real time by a Dogwood monitor built into the AgentCore Gateway ^[3][4].

The interesting part is where the check now sits. Policy in AgentCore was already positioned as controls applied across agents running in the service ^[1], and the earlier version could place restrictions on the input parameters of tools ^[6]. An argument check is stateless: you can decide it from the call in front of you. A prerequisite, an ordering requirement or a cumulative cap is not, and enforcing one means the monitor has to know what already happened. AWS says a Dogwood condition can examine either the call being decided or what has already happened in the same session ^[12]. That is session state held outside the model, which is the difference between asking an agent to behave and stopping it.

The evaluation semantics are conventional and worth knowing before anyone writes a rule. Dogwood is default-deny and a forbid overrides a permit, so a rule that grants a capability is written as a permit carrying conditions, while a rule that limits or caps something is written as a forbid ^[11].

Alongside this, AWS has extended Policy Authoring, which it describes as an AI-driven tool that converts natural language policy specification documents into syntactically and semantically correct Dogwood formal specifications ^[5]. It can now produce temporal and trajectory constraints, policies that invoke Amazon Bedrock Guardrails to detect inappropriate content in the semantic meaning of free-form text, and the parameter restrictions that existed previously ^[6]. That is three families of control, only one of which predates this launch ^[17].

The caveats in the post are the useful part for anyone budgeting the work. AWS says authoring is a translator rather than a summarizer, works best when the rules already exist in prose and the job is transcription rather than design, and that documents mixing rules with rationale and commentary should be pared down to the rules first ^[8]. Authoring also consumes a schema of tool names, arguments and return values generated from the agent's Model Context Protocol tool manifest, so the generated policies refer to the same names the agent actually calls ^[9]; in a generated policy, context.input.amount is the amount argument of the tool ^[16]. It is additionally given the set of available Guardrails checks and the identity claims a policy may reference ^[10]. And hand-writing remains supported: for a small set of controls, AWS says that is a perfectly reasonable place to start ^[7].

The worked example is a retail bank customer-servicing agent that verifies callers, files disputes, issues refunds against disputed charges, moves funds between a customer's own accounts and can ask a supervisor to approve a charge, with tools reached through the AgentCore Gateway ^[13]. Its compliance team keeps its controls in the same written document it uses for human staff ^[15], and one rule (refunds only between 9:00 AM and 5:00 PM UTC and only for amounts of $2,500 or less) becomes a single policy with two requirements ^[14].

Two things to watch. First, the coupling to the MCP manifest ^[9] makes tool renames a policy-breaking change, so manifest drift becomes a governance incident rather than a refactor. Second, the post does not describe latency, denial handling or how session state is bounded, which is what determines whether this is a control plane or a bottleneck.