AWS moves agent control outside the agent

AWS is turning a quiet but important corner in how enterprise AI agents are governed. A new Amazon Bedrock AgentCore update adds temporal policies and rate limits to the gateway layer. The point is not just to approve or deny one tool call. The point is to control the pattern of actions over time.

That matters because most agent risk does not appear as a single obviously bad request. A call to retrieve a customer profile may be legitimate. A later call to initiate a transaction may also look legitimate. The risk sits in the sequence, the identity, the amount, the timing and the state carried from one action to the next.

AWS describes several concrete failure modes. An agent may retrieve customer information and then move money to a different account. Each action can look valid in isolation. The problem is the combination. An agent can place several small orders below a threshold and still exceed the budget in aggregate. It can also enter retry loops and burn token spend overnight unless the infrastructure stops it.

AgentCore Gateway becomes the control point. It routes calls to MCP servers, models, agents and knowledge bases. When traffic passes through a common gate, the platform team can enforce policies across agents instead of asking every product team to build its own guardrails. That is the right direction for production systems.

The new part is temporal policy. The policy can inspect what happened earlier in the same session before the next action is allowed. A rule can require load_portfolio to run only after get_client_profile, and rebalance_portfolio only after the portfolio has actually been loaded. Another rule can ensure that the portfolio ID in a trade matches an ID returned by a previous verified call. A third can add up the value of several actions and stop the next one when the session crosses a limit.

This is governance of action chains, not just access management. For CISOs, the distinction is practical. It is the difference between trusting the agent to remember the policy and placing a deterministic control outside the model. AWS says the rules are enforced outside the agent code, hidden from the agent, deny-by-default and logged with context for audit.

The policy language behind this is Dogwood, a new open-source policy language for AI agents built on Cedar. Dogwood adds time windows, prerequisite steps, rate limits and escalation triggers. This is more than an AWS implementation detail. It points toward a broader market pattern: enterprises will need explainable agent controls that show what an agent was allowed to do, why it was stopped, which user it acted for and which session state mattered.

Rate limiting is the second part of the update. AWS lets teams set limits at gateway level for requests, token use and connection duration. That sounds technical, but it is budget and operational governance. Agent costs do not behave like traditional SaaS seats. They scale with steps, context, tool calls and failure loops. A cost control that only appears in a monthly finance report arrives too late.

The governance relevance is strongest in three areas. The first is financial services, insurance, healthcare and government, where agents may read sensitive information and then take or recommend action in the same session. Security teams need to define exactly which steps must happen first, which user identity is active, which value limits apply and when human approval is required.

The second is engineering and operations. Coding agents are being given terminal access, GitHub rights, internal APIs and deployment tools. Prompt-level control is not enough. If an agent reads malicious documentation and then tries to fetch secrets, open a network path or push code, it has to be blocked by infrastructure outside the model.

The third is procurement. Vendors increasingly sell agent platforms through polished demos. The executive question is not whether the agent can complete one task. It is how the platform controls sequences, cost, identity, tool calls, audit trails and human approval in production.

There is also a lock-in question. AgentCore is AWS. Enterprises already deep in the Amazon ecosystem get a natural route. Multi-cloud organisations should still pay attention to the pattern rather than the label. Agent control belongs in the infrastructure around the model, not in the model's good behaviour. Whether the control plane is AgentCore, Unity AI Gateway, Entra, an internal proxy or another platform matters less than whether it exists and is testable.

The board-level action is straightforward. Before more agents receive write access, companies should build a simple control matrix: which tools the agent can use, in which order, on behalf of whom, under which cost limit, and when approval is required. If the vendor cannot answer precisely, the agent is not ready for critical workflows.

This AWS update is not a guarantee of safe agent operations. It is still a sign that the market is moving from demo excitement to production control. Over the next year, the competitive difference will not be who has the cleverest agent in a demo. It will be who can let agents work while security, finance and audit still have a grip.

Kilder og medier

Source: AWS Machine Learning Blog, "Control agent behaviors and cost beyond a single action: new capabilities in Amazon Bedrock AgentCore", published 6 August 2026. https://aws.amazon.com/blogs/machine-learning/control-agent-behaviors-and-cost-beyond-a-single-action-new-capabilities-in-amazon-bedrock-agentcore

Thumbnail: OpenAI Image 2 / hogby.ai