AWS and PolicyLayer agree on the architecture: deterministic policy, evaluated at the gateway, outside the LLM reasoning loop, on every tool call. They differ on reach. AgentCore Policy governs the agents you build and run on Amazon Bedrock. PolicyLayer governs the MCP servers your team already runs, on any client and any cloud. Here is where each one fits.
Same enforcement architecture, validated by AWS in public. The open question is coverage: agents you build on Bedrock, or the MCP fleet you already run.
PolicyLayer is the hosted gateway your MCP traffic runs through. Connect your servers and every tool call is checked against deterministic, deny-by-default policy before it executes: allow, deny, rate-limit, or require approval, with argument-level rules and a per-call audit log. It works with any MCP client (Claude Code, Cursor, Codex, custom agents) and any server, including the third-party servers you do not control, and ships recommended policy pre-classified across 220,000+ catalogued tools.
AgentCore Policy is the authorisation layer in Amazon Bedrock AgentCore. Every agent tool call through the AgentCore Gateway is evaluated against policies written in Cedar, AWS's open-source authorisation language (now a CNCF Sandbox project), before the tool runs. AWS describes the layer as "a single checkpoint the LLM can't circumvent": deterministic, outside the model's reasoning loop, on the call with its arguments. It governs the agents you build and run on Bedrock AgentCore.
The same architecture, applied to two different surfaces. The dimensions that decide which one covers your fleet.
| PolicyLayer | AWS AgentCore Policy | |
|---|---|---|
| Architecture | Deterministic, at the gateway, outside the LLM reasoning loop | Deterministic, at the gateway, outside the LLM reasoning loop |
| Where it runs | Any MCP client (Claude Code, Cursor, Codex, custom) pointed at any server | Agents you build and run inside Amazon Bedrock AgentCore |
| Servers governed | The MCP servers you already run, including third-party servers you do not control | Tools wired into your AgentCore Gateway |
| Policy language | Deterministic JSON policy in a visual editor and as code | Cedar, AWS's open-source CNCF authorisation language |
| Granularity | Per tool and per argument (deny refunds over $1k, block DELETE without WHERE) | Per tool call, evaluated with its arguments |
| Starting policy | Recommended policy pre-classified across 220,000+ catalogued tools | Author Cedar policies from scratch |
| Identity | Per-person and per-agent scoped grant tokens routed through the gateway | AWS IAM and AgentCore identity |
| Approvals | Allow, deny, rate-limit, or require human approval on any call | Allow or deny in Cedar; custom logic (e.g. approvals) via Lambda gateway interceptors |
| Audit | Every call logged with the tool, its arguments, and the decision | Per-request authorisation decisions, auditable independently of the agent |
| Adoption | Point your client at a URL. Hosted, no platform team, no runtime to adopt | Adopt the Amazon Bedrock AgentCore runtime and platform |
| Best fit | Teams routing AI clients through MCP servers, on any cloud, without a platform team | Teams building and hosting agents on Amazon Bedrock |
Your team runs Claude Code, Cursor, or Codex against MCP servers. AgentCore Policy governs agents inside Bedrock; PolicyLayer governs the fleet you already run, on any client and any cloud.
Most of your MCP servers are third-party. PolicyLayer is the enforcement point that sits in front of servers you cannot modify.
Start from recommended rules pre-classified across 220,000+ tools, instead of authoring policy from a blank page.
Point your client at a gateway URL and enforce in minutes, with nothing to deploy and no agent platform to migrate onto.
Your agents run inside Amazon Bedrock AgentCore, and you want authorisation native to that runtime.
Your organisation already authors Cedar policy for other AWS services and wants one language across them.
Keeping the enforcement point within your AWS account and IAM model is a hard requirement.
They agree on the architecture, and AWS shipping it into Bedrock validates the category. If you run agents on Bedrock and also consume MCP servers outside it, AgentCore Policy governs the former and PolicyLayer governs the latter, with the same deterministic, at-the-gateway model on both.
Whatever your agents touch, the same engine, audit, and access model is doing the work underneath every rule you write.
Rules run as code, not model judgement: argument-level conditions, quotas, deny-by-default. The same call gets the same decision every time.
Writing policies →Your security or compliance team writes and attaches policy without ever holding the upstream credentials or grant tokens.
Roles →Every call is logged with its decision and the rule that fired, attributed to the identity, in an append-only record. Argument values are redacted, never stored.
Logs & security →Upstream secrets are encrypted at rest and injected by the gateway. The agent only ever holds a scoped token.
Logs & security →Every person and agent connects with its own scoped grant. Rotate or revoke any one of them instantly, without disrupting the rest.
Core concepts →Hosted gateway. Point your clients at it, register a server, issue a token. Nothing to install.
Quick start →No. PolicyLayer is cloud-agnostic. It governs any MCP client pointed at any server, whether or not you build on AWS. AgentCore Policy governs agents built and run inside Amazon Bedrock AgentCore.
Yes. Both evaluate every tool call deterministically, at the gateway, outside the LLM reasoning loop, on the call with its arguments. AWS chose Cedar for this; PolicyLayer uses its own deterministic JSON policy. The architecture is the same; the surface it covers differs.
Yes. PolicyLayer sits in front of third-party MCP servers you cannot modify and enforces policy on every call. AgentCore Policy governs the tools wired into your own AgentCore Gateway.
No. PolicyLayer has its own deterministic policy language, authored in a visual editor or as JSON, and ships with recommended policy pre-classified across 220,000+ catalogued tools so you start from known-risk rules rather than a blank page.
Deterministic, deny-by-default policy on every MCP tool call, on any client and any cloud: approval gates, per-identity scopes, argument-level rules, and a tamper-proof audit log. Route your existing MCP servers through the gateway, live in minutes.
Instant setup, no code required.