AWS Bedrock + ACP — Cross-cloud governance install guide

Amazon Bedrock is AWS’s managed foundation-model service, expanded in 2025–2026 into a full agent platform via Bedrock AgentCore — Policy (GA March 2026), Identity, Gateway, and Registry (preview April 2026). For agents that live entirely inside AWS — built with AgentCore-managed primitives, deployed to Bedrock runtimes, calling Bedrock-hosted models including OpenAI’s GPT-5.5 family on Bedrock — AgentCore is a serious governance surface.

What it doesn’t span: the rest of your AI stack. Claude Code in your developer’s terminal. Cursor in their IDE. Your CrewAI multi-agent setup running on Cloud Run. Your LangGraph supervisor pattern on Render. Your custom Anthropic-Agent-SDK orchestration on Fly.io. AgentCore Policy doesn’t reach those — they’re outside AWS’s interception boundary by design.

Agentic Control Plane is the layer that does. This page is the honest read on what AgentCore covers, what it doesn’t, and how the two compose into a single identity-attributed audit trail across every environment your agents run in.

TL;DR. Use AgentCore for governance of agents you build inside Bedrock’s runtime. Use ACP for everything else — and for unified audit across both. The patterns are complementary, not competitive.

What AgentCore ships

Quoted from AWS documentation and recent announcements:

• AgentCore Policy (GA March 2026, 13 regions): “centralized governance layer that sits outside agent code, intercepting and evaluating every tool call against enterprise-defined rules.” Natural-language policies compiled to AWS’s open-source Cedar policy language.
• AgentCore Gateway: tool-call interceptor with fine-grained access controls based on user identity and tool input parameters.
• AgentCore Identity: per-user identity propagation across service boundaries — JWT/OIDC trusted issuers, scoped credentials for downstream API calls.
• AgentCore Registry (Preview April 2026): centralized agent and tool catalog, governance-aware.
• CloudWatch metrics + logs: every enforcement decision logged for audit and compliance review.

The footprint is complete and enterprise-credible for AWS-hosted agents. AWS positioning frames it as “the trust layer for enterprise AI” — accurate within Bedrock’s boundary.

Where AgentCore stops

Three architectural realities:

1. Bedrock-hosted only. AgentCore Gateway intercepts agents that call AWS-hosted Bedrock primitives. A Claude Code session on your developer’s laptop, a Cursor agent calling MCP servers, a CrewAI deployment on Cloud Run — none of these route through AgentCore. They’re outside AWS’s interception surface.
2. Single-cloud. Identity, audit, and policy are unified inside AWS. A multi-cloud team running agents on AWS + GCP + Azure has three separate audit logs, three policy engines, three identity reconciliation problems.
3. Bedrock model boundary. Customers using Bedrock-served OpenAI or Claude models inherit Bedrock’s governance for the model call. Customers calling those same models from outside Bedrock (direct OpenAI API, direct Anthropic API) don’t.

These aren’t bugs — they’re architectural choices. AgentCore is built to be the AWS-native answer. It does that well.

Where ACP plugs in

ACP intercepts at the tool dispatch layer (or the LLM proxy layer, your choice) of any agent runtime — regardless of which cloud the agent runs on. Three concrete integration paths:

Path 1 — Self-built agents calling Bedrock-hosted models (works today)

You’re using the Anthropic Agent SDK, OpenAI Agents SDK, or your own loop. Your agent calls Bedrock-hosted models for inference. Tool execution happens in your code, in your infrastructure.

# Tool layer — every dispatch governed by ACP
from acp_governance import configure, governed, set_context

configure(base_url="https://api.agenticcontrolplane.com")

@governed("query_warehouse")
def query_warehouse(sql: str) -> dict:
    return warehouse.execute(sql)

# LLM call goes direct to Bedrock — your tool calls flow through ACP

Result: tool-call audit, identity propagation, output redaction across all your tools — independent of where the LLM lives. Same code works whether you call Bedrock, Anthropic direct, or both. See the OpenAI Agents SDK integration and Anthropic Agent SDK integration for the framework-specific recipe.

Path 2 — AgentCore Gateway as MCP downstream (composable)

You’ve adopted AgentCore Gateway for your AWS-hosted agents. Their custom action groups call out to your MCP servers. ACP can be one of those MCP servers — exposed at mcp.agenticcontrolplane.com/mcp, governed downstream of AgentCore’s identity propagation. Your audit trail then links: AgentCore (per-call AWS identity) → ACP (tool-output PII scan, cross-tenant audit, policy enforcement on the actual action).

The two layers compose: AgentCore enforces who-can-call, ACP enforces what-the-tool-does. Different concerns, complementary audit.

Path 3 — Bedrock-hosted agents calling external tools

Your AgentCore agent has an Action Group that hits a non-AWS endpoint — your CRM, a partner API, an internal service running on GCP. AgentCore Gateway’s interception covers the call (allow/deny based on policy). It doesn’t cover what the tool does once the call is dispatched, including PII in the response.

ACP runs at the tool boundary. Wrap the Lambda handler that backs the Action Group with @governed, and the response gets PII scanning, secret redaction, and audit row before it returns to the agent. The two layers cover different attack surfaces.

Honest comparison

Most enterprises need both — AgentCore for AWS-native agents that benefit from deep IAM integration; ACP for the agents and clients that don’t run in AWS, plus the unified audit layer that sees across every environment.

Install

If you’re using a self-built agent (Path 1):

# Python
pip install acp-governance
# TypeScript
npm install @agenticcontrolplane/governance

If you’re using a coding agent (Claude Code, Cursor, Codex CLI):

curl -sf https://agenticcontrolplane.com/install.sh | bash

Both flow into the same ACP workspace. Audit at cloud.agenticcontrolplane.com/activity.

Limitations

• AgentCore-internal calls aren’t visible to ACP. When an AWS-hosted agent calls another AWS-hosted agent through AgentCore Gateway, the call stays inside AWS — we don’t see it. Use AgentCore’s own audit for those.
• Bedrock model calls aren’t intercepted by ACP. If you want LLM-call audit, ACP’s OpenAI-compatible proxy works for the OpenAI surface, but Bedrock’s own runtime is the right interception point for Bedrock-managed model calls.
• No automatic IAM-to-ACP-policy mirror. AgentCore policies and ACP policies are two policy stores. We don’t auto-sync. For policy-parity we recommend writing the high-level rule (e.g., “deny wire_transfer in background tier”) in both — or routing all governance through one and the audit through the other.

Related

• Anthropic Agent SDK integration — for governing self-built agents that call Bedrock-hosted Anthropic models
• OpenAI Agents SDK integration — for governing self-built agents that call Bedrock-hosted OpenAI models
• ChatGPT Workspace Agents — equivalent honest read for OpenAI’s hosted agent surface
• Google Agents CLI — equivalent for Google’s hosted surface
• Reference architecture — how ACP composes with cloud-native governance layers