Amazon Bedrock AgentCore gets Policy to control AI agent access

Amazon has described a new, separate Policy mechanism in Bedrock AgentCore for protecting AI agents. Its job is to check access to tools and data not by the model's "common sense" but by hard rules that run independently of its reasoning, moving security out of prompts and into a managed infrastructure layer.

A separate layer of rules

The key idea is that Policy in AgentCore creates a deterministic control layer. Even if the agent decides that, to answer a question, it should open an internal service, download a file, or call a tool with elevated privileges, the final decision is not its own. The request passes through a separate rule system, and only that system determines whether the action is allowed.

This approach reduces the risk of the model misreading instructions, interpreting the user's task too broadly, or trying to reach data it is not supposed to see.

AWS also describes a more convenient way to configure such restrictions. Business rules can first be written in natural language and then translated into Cedar policies. Cedar is a language designed for precisely describing permissions. Instead of a vague prompt such as "don't show other people's documents," there is a formal check: who, under what conditions, and with what rights can actually open a given tool or dataset through the agent. For enterprise scenarios, this matters more than yet another layer of instructions inside the prompt itself.

This is especially important for agents in long, multi-step scenarios. A model may start a task correctly and then, midway through the chain, decide it needs another tool or broader access. Without an external policy, such expansions are often controlled only by the prompt. Policy in AgentCore offers a stricter scheme: every new step is checked against the rules again, even if the agent itself is sure it is acting in the user's interest.

Checking at the gateway

In practice, Policy is applied through AgentCore Gateway. This gateway intercepts every request from the agent to a tool at runtime and checks it before the action is executed. In other words, this is not a one-time setup at the start of a session but runtime control: an agent may call APIs, databases, file stores, and internal services dozens of times, and each of those steps is evaluated against the policy. This keeps protection closer to the agent's actual behavior rather than its initial intentions.

• Who exactly initiated the request: a specific user, role, or group
• Which tool the agent is calling and what action it wants to perform
• Whether the user has the right to see this data or run this workflow
• Whether access should be denied, allowed, or narrowed depending on context

The main emphasis here is identity-aware access. The agent does not receive an abstract permission to "work with the CRM" or "read documents" but rights tied to the identity and authority of the user on whose behalf it acts. If an employee can access only some of the customer records, the agent must see the same boundary. If a manager has access to one set of tools and an analyst to another, that too must be enforced automatically.

This approach is particularly useful where the same agent serves different employees with different access levels. As a result, Bedrock AgentCore offers not just guardrails for responses but a stricter model for governing actions.

What this means

Amazon is moving toward more mature AI agents for companies, where predictable rule enforcement matters as much as a smart interface. If this approach catches on, businesses will be able to connect agents to internal systems without constantly hoping the model behaves carefully. Access control will become an external, verifiable layer, which means it will be easier to trust agents with real tasks, from searching data to launching tools on an employee's behalf.