# AWS Bedrock + ACP — Cross-cloud governance install guide

Bedrock AgentCore handles AWS-hosted agents. ACP handles the rest of your stack. Here's how the two compose, and what each covers natively.

# 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](https://aws.amazon.com/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](https://aws.amazon.com/bedrock/openai/) — 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.

```python
# 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](/integrations/openai-agents-sdk) and [Anthropic Agent SDK integration](/integrations/anthropic-agent-sdk) 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

| Dimension | AgentCore | ACP | Best together |
|---|---|---|---|
| Cloud breadth | AWS only | AWS, GCP, Azure, on-prem, multi-cloud | ACP for non-AWS, AgentCore for AWS-native |
| Framework breadth | Bedrock-hosted agents | Claude Code, Cursor, Codex, Zed, CrewAI, LangGraph, Anthropic SDK, OpenAI Agents SDK, Mastra, Pydantic AI, Vercel AI SDK, AutoGen, Google ADK | ACP for the long tail, AgentCore for Bedrock |
| Identity model | AWS IAM + Cognito | Any OIDC / OAuth / Firebase / Auth0 | ACP for non-AWS IdPs, AgentCore for native AWS auth |
| Policy DSL | Natural language → Cedar | JSON policies + ABAC + plan-based limits | Either; both are policy-aware |
| Audit destination | CloudWatch | Structured, queryable, exportable (CSV), built-in dashboard | ACP if you want unified non-AWS audit |
| Cost model | AWS bill (per AgentCore call + storage) | Free up to 5 agents; flat bands above ($100/mo covers 25) | Stack: pay AWS for AgentCore, ACP for the rest |

**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):

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

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



Both flow into the same ACP workspace. Audit at [cloud.agenticcontrolplane.com/activity](https://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](/integrations/anthropic-agent-sdk) — for governing self-built agents that call Bedrock-hosted Anthropic models
- [OpenAI Agents SDK integration](/integrations/openai-agents-sdk) — for governing self-built agents that call Bedrock-hosted OpenAI models
- [ChatGPT Workspace Agents](/integrations/chatgpt-workspace-agents) — equivalent honest read for OpenAI's hosted agent surface
- [Google Agents CLI](/integrations/google-agents-cli) — equivalent for Google's hosted surface
- [Reference architecture](/reference-architecture) — how ACP composes with cloud-native governance layers