AI Defense Stack

Agent & MCP security

Amazon Bedrock AgentCore Policy: managed policy engine for agent tool calls

AgentCore Policy is a managed policy engine for agent tool calls from Amazon Web Services. It is a commercial product offered as: Managed service, Cloud-native, API, CLI. Pricing model: usage-based.

  • Last reviewed
Visit AgentCore Policy (opens in a new tab) Documentation (opens in a new tab)
Commercial Layer 7: Agent and tool access

Best for

Teams that run agent tools behind AgentCore Gateway on AWS and want deterministic allow and deny rules on tool calls, based on who calls and what the call contains

Consider instead if

  • You want an open-source sandbox with permit and forbid rules that runs on your own machine. See Strands Box.
  • You want a gateway that is not tied to one cloud. See agentgateway.

What AgentCore Policy does

Policy in Amazon Bedrock AgentCore is an AWS service that intercepts agent tool calls at an AgentCore Gateway and checks each one against policies in a policy engine before the tool runs. Policies are written in Cedar or Dogwood, or described in plain English and translated, and the engine denies by default and lets any forbid rule win. Rules can use the caller's identity, tool input values, session history and, through Amazon Bedrock Guardrails, prompt attack or sensitive data scores. Decisions are logged to CloudWatch, and a log-only mode lets you test without blocking. It works only through AgentCore Gateway, is priced per authorization request, and is not open source.

This summary is our own wording of the sourced facts on this page.

Key facts

Each value links to the page that states it, with the date we checked it.

Vendor
Amazon Web Services Source, checked October 21, 2026: docs.aws.amazon.com (opens in a new tab)
Status
Active Source, checked October 21, 2026: aws.amazon.com (opens in a new tab)
Open source
No: closed source (proprietary) Source, checked October 21, 2026: docs.aws.amazon.com (opens in a new tab)
Latest release
Not documented in the sources we checked
Deployment
Managed service, Cloud-native, API, CLI Source, checked October 21, 2026: docs.aws.amazon.com (opens in a new tab)
Pricing model
Usage-based: Authorization requests: $0.000025 per request. The first 100 temporal policies per policy engine incur no additional authorization charges. Natural language authoring and guardrail use are billed separately. (as listed on October 21, 2026; check the vendor for current pricing) Source, checked October 21, 2026: aws.amazon.com (opens in a new tab)
Website
docs.aws.amazon.com Source, checked October 21, 2026: docs.aws.amazon.com (opens in a new tab)
Documentation
docs.aws.amazon.com Source, checked October 21, 2026: docs.aws.amazon.com (opens in a new tab)
API reference
docs.aws.amazon.com Source, checked October 21, 2026: docs.aws.amazon.com (opens in a new tab)
Quickstart
docs.aws.amazon.com Source, checked October 21, 2026: docs.aws.amazon.com (opens in a new tab)
Security page
Not documented in the sources we checked
Attestations or disclosure
Not documented in the sources we checked

Capabilities

As documented by the vendor or project. The tag is our label from a controlled vocabulary.

Integrations

Where AgentCore Policy fits in our AI security layers

Our analysis

Our editorial model, not a standard. The primary layer follows the category, except for tools whose main documented job is detection and response; other layers rest on a capability the sources document. How the model works.

AI security layers that AgentCore Policy covers, with the role, how each applies and what it rests on
LayerRoleHow it appliesBased on
L7 Agent access Agent and tool access Primary Limit which tools, MCP servers, data and credentials an agent can use, and require approval for risky actions. Follows its category, Agent & MCP security
L6 Runtime Runtime guardrails Also covers Guardrail conditions screen tool input and output for prompt attacks and sensitive data through Bedrock Guardrails. Guardrail conditions call Bedrock Guardrails for prompt attack, content and sensitive data scores; a policy can deny a call or suppress a tool response
L8 Monitoring Monitoring and response Also covers Documents logging of every enforcement decision to CloudWatch, including a log-only mode. Logs every enforcement decision to CloudWatch, and a LOG_ONLY mode records decisions without blocking requests

OWASP LLM Top 10 mapping

Our analysis

The risk list is OWASP's (Top 10 for LLM Applications, 2025). The mapping is our analysis, and each row rests on a capability the sources document.

OWASP LLM risks mapped to AgentCore Policy, with the capabilities each mapping rests on
RiskHow it appliesBased on
LLM01 Prompt Injection Policies can forbid a tool call when a Bedrock Guardrails prompt attack score for the input passes a threshold. Guardrail conditions call Bedrock Guardrails for prompt attack, content and sensitive data scores; a policy can deny a call or suppress a tool response
LLM02 Sensitive Information Disclosure A suppressOutput policy can withhold a tool response when a sensitive information guardrail finds items such as an SSN. Guardrail conditions call Bedrock Guardrails for prompt attack, content and sensitive data scores; a policy can deny a call or suppress a tool response
LLM06 Excessive Agency Default-deny rules by caller identity and tool input values limit which tool calls an agent can make. A policy engine evaluates policies for every tool call through an associated gateway, enforcing default deny and forbid-wins outside the agent's code; Fine-grained permissions by caller identity (OAuth claims or IAM identity) and by tool input values, such as a refund amount limit; Temporal rules in Dogwood use earlier actions in the same session, such as requiring a prior approval or capping how often an action runs; Policies can be written in plain English and are translated to Cedar, validated against the tool schema and checked for overly permissive or restrictive rules

Not mapped in our analysis: LLM05, LLM07. These are risks we expect tools in this category to cover; the sources we checked do not document a matching capability.

Alternatives and related tools

More in Agent & MCP security, ranked within the category by Coverage Score.

Cisco DefenseClaw

Cisco

Open sourceApache-2.0
  • CLI
  • Self-hosted

Scans skills and MCP servers, inspects agent tool calls and keeps an audit trail around AI coding agents.

Best for: Security teams that want scanning, guardrails and an audit trail around the coding agents developers already run, starting in observe mode before anything is blocked

Coverage Score 76 out of 100
  • LLM01 Prompt Injection
  • LLM02 Sensitive Information Disclosure
  • LLM06 Excessive Agency

Reviewed

Docker MCP Gateway

Docker

Open sourceMIT
  • CLI
  • Self-hosted

Proxies AI clients to MCP servers it runs as isolated Docker containers, with tool filters and call logs.

Best for: Developers and platform teams that already use Docker and want MCP servers to run in containers behind one gateway with per-server tool selection

Coverage Score 72 out of 100
  • LLM02 Sensitive Information Disclosure
  • LLM06 Excessive Agency

Reviewed

agentgateway

agentgateway (a Series of LF Projects, LLC)

Open sourceApache-2.0
  • CLI
  • Self-hosted
  • Cloud-native

Open-source proxy that applies auth, CEL policy and guardrails to LLM, MCP and agent-to-agent traffic.

Best for: Platform teams that want one open-source gateway in front of MCP servers and LLM providers, with token validation, CEL rules per MCP method and pluggable guardrails

Coverage Score 69 out of 100
  • LLM02 Sensitive Information Disclosure
  • LLM06 Excessive Agency

Reviewed

AgentCore Policy FAQ

What does AgentCore Policy actually check?

Each tool call that passes through an AgentCore Gateway. The docs say the policy engine evaluates every request against its policies before the agent gets tool access, and denies anything no policy permits.

Can it test rules without blocking traffic?

Yes. The docs describe a LOG_ONLY enforcement mode in which decisions are logged to CloudWatch and no requests are blocked, and they suggest using it to calibrate guardrail thresholds.

Does it work with agents that do not use AgentCore Gateway?

The docs describe Policy as intercepting agent traffic through AgentCore Gateways and associating policy engines with gateways. The pages we read describe no enforcement path that skips a gateway.

Key facts you can cite

We have no commercial relationship with Amazon Web Services.

Sources & last reviewed

Last reviewed . We compile from the vendors' own public pages and repositories and we do not run the products. Source links open in a new tab. Found a mistake? Report a correction.