ACP and Bedrock AgentCore: how the two layers compose
AWS shipped a real governance product. Bedrock AgentCore Policy went GA in March 2026 across 13 regions. AgentCore Identity, Gateway, and Registry (preview) round out a control-plane shape that overlaps maybe 70% with what we ship. AWS framing — “the trust layer for enterprise AI” — is the same shelf we sit on.
So a fair question: do you need ACP if you’re on AWS?
Honest answer: depends on whether your AI stack ends at AWS. If it does, AgentCore is the right primary surface. If it extends — and for almost everyone it does — you need a layer above.
What AgentCore covers well
- AgentCore Policy: natural-language policies compiled to Cedar, enforced at AgentCore Gateway, deterministic (not probabilistic) — the gateway intercepts before the model can reason around it.
- AgentCore Identity: per-user identity propagation across AWS service boundaries. JWT/OIDC trusted issuers, scoped credentials for downstream calls. The closest any cloud has come to a clean identity-flows-end-to-end story for AWS-hosted agents.
- AgentCore Gateway: tool-call interceptor with fine-grained access controls (user identity + tool input parameters).
- AgentCore Registry (preview): centralized agent + tool catalog with governance hooks.
- CloudWatch logs: every enforcement decision recorded.
For AWS-native enterprises — Fortune 500 teams running on Bedrock-hosted Claude or now Bedrock-hosted OpenAI models — this is real. Policies live outside agent code. New agents inherit existing rules. Security teams operate the policy engine separately from agent developers. No bespoke governance code to maintain.
If your agents live in Bedrock, you should probably use it.
What’s outside AgentCore’s scope
AgentCore is designed to govern at AWS’s interception boundary. Three categories of agent activity sit outside that architectural surface — by design, not by oversight:
1. Coding agents on developer laptops. Claude Code, Cursor, Codex CLI, Zed — these run locally on developer machines, talk to model providers directly, and don’t route through Bedrock. The interception point that fits them is the agent runtime’s own hook surface (PreToolUse / PostToolUse), which is a different architectural layer than the AgentCore Gateway.
2. Agent code that runs anywhere else. A CrewAI deployment on Render. A LangGraph supervisor on Cloud Run. A custom Anthropic Agent SDK orchestration on Fly.io. A Pydantic AI agent on customer-controlled Kubernetes. These aren’t AWS-hosted, so they’re outside AgentCore’s enforcement surface — a tool-call-level interception in the agent code is the natural fit instead.
3. Multi-cloud workloads. Real enterprises run agents across AWS, GCP, and Azure. AgentCore unifies governance inside AWS, which is exactly its intended scope. Cross-cloud unification — same audit log across clouds — is a separate architectural concern that lives above any single cloud’s product.
These aren’t bugs in AgentCore. They’re the natural boundary of what an AWS-native control plane is built to govern. A complete governance picture composes layers at multiple intercept points.
Where ACP composes alongside AgentCore
Three concrete intercept points ACP adds at a different architectural layer:
- Cross-cloud unified audit. Same audit log across AWS-hosted agents, GCP-hosted agents, Azure-hosted agents, and developer-laptop coding agents. Your CISO’s “what did our AI do for user X this week?” gets one query, not a six-system join.
- Cross-framework breadth. 15 framework / client integrations: Claude Code, Cursor, Codex CLI, Zed, Cline, Claude Desktop, Anthropic Agent SDK, OpenAI Agents SDK, Google ADK, CrewAI, LangGraph, Mastra, Pydantic AI, Vercel AI SDK, AutoGen. AgentCore covers one shape: Bedrock-hosted agents.
- Per-end-user identity propagation outside AWS IdPs. AgentCore Identity is excellent if your IdP is Cognito or you’re trusting external OIDC for AWS callers. ACP works the same way regardless of which IdP — Auth0, Okta, Firebase, Google, custom — and routes through to non-AWS APIs.
How to compose them
Most enterprises with serious AI deployments end up running both. Three composition patterns:
Pattern 1 — AgentCore for AWS, ACP for everything else
Default for multi-cloud or developer-tool-heavy environments:
- AWS-hosted Bedrock agents → AgentCore Policy + Gateway
- Non-AWS agents (CrewAI on Render, LangGraph on Cloud Run, Cursor on dev laptops) → ACP
- Cross-environment audit → forward CloudWatch logs into your SIEM alongside ACP’s webhook stream, join on session/request IDs
Pattern 2 — ACP as MCP backend for AgentCore
If your AgentCore agents call out to MCP servers (custom action groups, partner APIs), register mcp.agenticcontrolplane.com/mcp as one of those MCP servers. AgentCore’s frozen-snapshot policy approves the schema; ACP enforces per-call policy + PII redaction + audit downstream. Two layers, different concerns.
Pattern 3 — ACP at the tool-handler layer for Action Groups
Your AgentCore agent has an Action Group backed by a Lambda. Wrap the Lambda handler with @governed. AgentCore controls who-can-call; ACP controls what-the-tool-does and what-comes-back. Defense in depth.
When you don’t need ACP
You only need AgentCore if all of these are true:
- All your agents run inside Bedrock
- You don’t have Claude Code, Cursor, or other developer-laptop coding agents in scope
- Your team only uses AWS — no multi-cloud
- Your IdP is Cognito or you’re comfortable mapping every external IdP into AWS-native identity flow
For shops with that profile, AgentCore alone is sufficient. For everyone else, the question isn’t “AgentCore or ACP” — it’s how the two compose.
The short version
AgentCore is the right answer for AWS-hosted agents. ACP is the right answer for agents that don’t fit inside AWS, and for the unified-audit story when you have both. Most enterprises with real AI deployments run both, and the integration is well-defined enough that neither layer fights the other.
Detailed install: /integrations/aws-bedrock.
Reference architecture → · Get started →