AWS announces three governance functions for Bedrock AgentCore: temporal policies based on Dogwood (an open source policy language for AI agents), rate limiting on the gateway, and visibility through CloudWatch.

Temporal policies are stateful rules: they evaluate whether an agent is authorized to perform an action based on its session history, not just the single action. You can enforce workflow order (fetch data first, then write), block data fabrication, cap financial exposure, and require human approval for high-value actions.

Rate limiting protects targets: you define request, token, and connection limits per user and per destination, with rules anchored to IAM identity or JWT claims. If an agent enters a loop and starts calling a model or tool without stopping, the gateway blocks it before it burns through your budget.

Visibility comes through CloudWatch: metrics on what the agent does, how much it spends, where it breaks.

Why this matters to you. If you’re deploying agents to production, the model already knows how to do the job. What’s missing is preventing it from doing the wrong thing at the wrong time, and knowing what it costs before you find out the hard way. As we covered yesterday on AgentCore GA, the center of gravity shifts from chat to runtime. These three features are the governance that makes that runtime usable outside a demo.

The pattern is the same one Cloudflare described three days ago with its zero-trust model for agents: temporary credentials, behavioral gateway, spending cap. AWS closes the same loop on its stack.

In detail

What existed before.

Until now, controlling an agent on Bedrock meant evaluating every single action. You could allow or deny a tool call, but you couldn’t say: “this agent can call the write tool only after calling the read tool.” Authorization was stateless. The agent could take steps in the wrong order, repeat the same action infinitely, accumulate cost with no session-level control to stop it.

What changes with temporal policies.

Dogwood is an open source policy language, built for AI agents. Temporal policies written in Dogwood track session state: every time the agent wants to do something, the policy looks at what it has done so far and decides if the action is allowed.

AWS lists four use cases:

• Workflow sequencing: the agent must complete step A before it can execute step B. A deterministic rule, not a prompt suggestion.
• Fabrication prevention: block the agent if it tries to produce data without first retrieving it from a verified source.
• Financial cap: set a spending limit per session. When the agent reaches it, it can’t make any more paid calls.
• Human approval: for high-value actions (a bank transfer, a production database change, sending email to a list), the policy stops the agent and waits for a person to say yes.

What changes with rate limiting.

The AgentCore gateway sits between the agent and the models or tools it calls. With rate limiting, you configure limits per user and per destination: maximum requests, tokens consumed, simultaneous connections. Limits are anchored to identity (IAM or JWT claims), so you can give different rates to different users or roles.

The real scenario: an agent has a bug, enters a loop, and calls the same endpoint a hundred times per second. Without rate limiting, downstream collapses and your bill spikes. With rate limiting, the gateway throttles the calls and the agent stops.

What changes with CloudWatch.

Metrics on agent behavior, cost, and errors go into CloudWatch. If you already use AWS, there’s no new tool to learn: the alarms and dashboards you already use for the rest of your infrastructure now cover agents too.

What we don’t know yet.

The three AWS blog posts are product announcements with configuration examples, but no numbers on latency or overhead of temporal policies. Dogwood is open source, but it’s new: the ecosystem of people using and stressing it outside demos is still forming. Rate limiting and CloudWatch metrics are standard gateway features, so the risk there is lower. The real question is how much friction temporal policies add to the agent’s critical path: every action passes through a stateful check, and at scale this matters. AWS doesn’t publish benchmarks. For anyone evaluating, the honest thing is to test it on your own load before trusting the timings.