AWS just made the case for deterministic policy at the MCP gateway

#mcp #security #aws #cedar

In May, AWS published an engineering post explaining why Policy in Amazon Bedrock AgentCore chose Cedar to govern agentic workflows. Most of the coverage read it as "AWS ships agent security." The signal that matters is narrower and far more important: the largest cloud provider on earth independently arrived at the exact architecture for controlling AI agents — deterministic policy, evaluated at the gateway, outside the model's reasoning loop, on every tool call.

When AWS builds the same thing you have been shipping, the architecture stops being a bet. It becomes consensus.

What AWS actually built

AgentCore Policy is the authorisation layer inside Amazon Bedrock AgentCore. The AgentCore Gateway sits between an agent and the tools it calls over MCP, and every request is evaluated against Cedar policies before the tool runs. AWS is precise about why that boundary has to sit where it does:

"Centralizing authorization outside both gives you a single checkpoint the LLM can't circumvent; one that's auditable and can be verified independently of the application code."

And on the deeper reason the model cannot be trusted to police itself:

"The LLM's plan is the thing you can't trust — it can't be responsible for enforcing its own constraints."

Cedar itself is the right tool for the job for one reason above all others, and AWS names it directly:

"Unlike probabilistic AI models, enterprise security requires deterministic guarantees. Cedar policies always produce the same authorization decision for identical requests, regardless of evaluation order or system state."

This is not a feature announcement. It is an architecture argument, and it is the same one PolicyLayer was founded on.

The four principles, now shared

Strip the branding from both systems and the same four design decisions remain. AWS arrived at them for Bedrock; we arrived at them for the MCP fleet teams already run. They agree completely.

Enforcement lives outside the LLM. A control the model can reason about is a control the model can reason around. Prompt injection, hallucination, and context drift all act on the model's plan. Move the decision out of the plan and those attacks have nothing to grab.
The decision point is the gateway. Every tool call passes through one boundary, and the boundary decides. Not the agent's code, not the server's implementation — a single checkpoint on the path.
The unit of control is the tool call, with its arguments. Not "can this agent reach Stripe," but "can this call refund this amount." AWS evaluates "the MCP tool invocation with the given arguments." So do we.
The decision is deterministic. Identical request, identical verdict, every time, independent of model or prompt. This is the property that makes the control provable to an auditor and immune to being talked out of.

The NSA reached the same place from the defensive side a month earlier — its MCP security report describes, recommendation by recommendation, the surface area of an in-path policy decision point. Two of the most security-serious institutions in the industry, arriving independently at one architecture, is about as strong a signal as this field produces.

Same decision, two syntaxes

The clearest way to see the agreement is to write the same rule in both systems. Take a common one: deny any refund over $1,000, and let a human handle the exceptions.

In Cedar, as AgentCore evaluates it:

forbid (
  principal,
  action == Action::"refund_payment",
  resource
)
when { context.amount > 1000 };

In PolicyLayer's policy language, evaluated at the gateway on every call:

{
  "version": "1",
  "default": "deny",
  "tools": {
    "refund_payment": {
      "deny_if": [
        {
          "conditions": [
            { "path": "args.amount", "op": "gt", "value": 1000 }
          ],
          "on_deny": "Refund exceeds the $1000 policy limit."
        }
      ]
    }
  }
}

Different keywords, identical behaviour: the call is inspected, the argument is read, the verdict is fixed before anything reaches the upstream server. No prompt reaches either rule. That is the whole point.

Where the two diverge

AgentCore Policy is a serious piece of engineering, and if you are already building on Bedrock it is the natural place to put your controls. The divergence is not quality. It is reach.

	AWS AgentCore Policy	PolicyLayer
Architecture	Deterministic, at the gateway, outside the loop	Deterministic, at the gateway, outside the loop
Where it runs	Agents you build and run inside Amazon Bedrock AgentCore	Any MCP client — Claude Code, Cursor, Codex, custom — pointed at any server
Servers governed	Tools wired into your AgentCore Gateway	The third-party MCP servers you already run, including ones you don't control
Adoption cost	Adopt the Bedrock AgentCore runtime and platform	Point your client at a URL. Nothing to deploy, no platform team
Starting policy	Author Cedar from scratch	Recommended policy, pre-classified across 220,000+ catalogued tools

AgentCore Policy governs the agents you build on AWS's platform. But most teams did not get into MCP by building a platform. They got into it because Claude Code spread across the engineering org, then Cursor, then a half-dozen MCP servers landed in shared configs, none of which the team wrote and most of which they cannot modify. That fleet needs the same architecture AWS just validated — applied to servers AWS's product was never going to reach, without asking the team to stand up a runtime they don't want to own.

Why this matters

For two years the hardest part of selling deterministic agent governance was convincing people the category existed. That argument is over. The NSA documented the need; AWS shipped the architecture into its flagship agent platform and explained, in public, exactly why probabilistic controls are not enough. The question facing a team running agents in production is no longer whether tool calls should be governed deterministically at the boundary. It is where yours run — and whether the boundary covers the servers you actually use, or only the ones inside one cloud's walls.

The architecture is settled. Coverage is the open question. That is the one PolicyLayer answers.