{"slug": "govern-ai-agent-tool-access-with-amazon-bedrock-agentcore-gateway", "title": "Govern AI agent tool access with Amazon Bedrock AgentCore Gateway", "summary": "Amazon Web Services (AWS) introduced Amazon Bedrock AgentCore Gateway, a managed service that provides a single secure entry point for AI agents to access organizational tools, addressing risks such as credential sprawl, policy drift, audit gaps, cost opacity, and shadow IT. The service integrates with AgentCore Identity for authentication and AgentCore Policy for security controls, and can be augmented with Amazon Bedrock Guardrails and AWS Agent Registry. AWS recommends a four-scope maturity journey to match controls to actual needs rather than building a complete gateway upfront.", "body_md": "[Artificial Intelligence](/blogs/machine-learning/)\n\n# Govern AI agent tool access with Amazon Bedrock AgentCore Gateway\n\nIn our conversations with customers over the past months, one pattern keeps recurring. Whether they work with coding agents, autonomous agents, or human-interactive ones, and regardless of workload maturity, we start with the same question: “Which AI agents have access to customer data, who granted it, and what would exposure look like if a credential leaked today?” If nobody in your organization can answer that in under a minute, this post is for you.\n\nWhen AI agents connect to internal tools without centralized governance, organizations encounter access risks that are difficult to detect. Consider an infrastructure engineer opening a teammate’s laptop to debug a build. In the config folder sits a file named `mcp.json`\n\ncontaining a production database password in plain text, next to a comment that reads TODO: rotate this. The security team has no visibility into which AI agents are reaching internal tools, who granted the access, or what the exposure would be if that credential were inadvertently exposed.\n\nThe proposed solution uses Model Context Protocol (MCP)-enabled assistants, including IDE helpers like [Kiro](https://kiro.dev/), [Claude Code](https://docs.anthropic.com/en/docs/claude-code/overview), Cursor, and AI tools like [Amazon Quick](/quick/). This post focuses on the AWS managed service Amazon Bedrock AgentCore, a platform to build, connect, and optimize agents at scale with any framework or model. With [AgentCore Gateway](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html) (a capability of Amazon Bedrock AgentCore), you provide a single, secure entry point to your organizational tools for agentic traffic. It relies on [AgentCore Identity](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity.html) (a capability of Amazon Bedrock AgentCore) for secure authentication, authorization, and credential management. To define and enforce security controls for AI agent interactions with tools, you use [AgentCore Policy](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html). You can then augment the policy with safety and privacy controls using [Amazon Bedrock Guardrails](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html), and build a centralized catalog for organizing, curating, and discovering tools using [AWS Agent Registry](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/registry.html). Self-hosted options ([Kong Gateway](https://konghq.com/products/kong-gateway), [Open Policy Agent](https://www.openpolicyagent.org/), [NeMo Guardrails](https://docs.nvidia.com/nemo/guardrails/home), and [LangFuse](https://langfuse.com/)) also exist, and this post calls them out where relevant.\n\n## The problem\n\nThere are five structural breakdown patterns in enterprise systems with MCP deployments, commonly described as: credential sprawl (secrets in every local config), policy drift (N×M configurations diverging silently), audit gaps (no answer to “who invoked what, when”), cost opacity (spend unattributable to teams), and shadow IT (integrations deployed outside review).\n\nTake policy drift as an example. Each AI assistant carries its own `mcp.json`\n\n, a local file with backend credentials and tool endpoints, without oversight. A team with 10 assistants connecting to 5 internal APIs maintains 50 independent credential sets, each configured by hand. When a policy changes in one backend, it must be updated in all 50 places.\n\nRecall the earlier question: which assistants access customer data, and who granted it? Most teams respond by building a complete gateway before allowing any AI use, which takes months and ships the wrong thing. We recommend matching controls to actual needs instead.\n\n## The solution: a four-scope maturity journey\n\nA governed gateway provides one governed endpoint, knows who is calling and under what authority, enforces policy at the tool and parameter level, and logs every decision. Teams can also publish tools without tickets. Each scope delivers standalone value while preserving the path to the next.\n\n**Scope 1: Connect.** One governed door so AI agents can reach organizational resources. When MCP credentials sit in local config and security has no inventory, apply SSO authentication, centralize credentials, and enable CloudTrail audit.\n\n**Scope 2: Control.** Know who did what, and scrub sensitive data on the way through. When you can’t answer “who invoked which tool, when, under which policy?”, apply Cedar RBAC/ABAC, PII redaction, 3LO consent, and DCR.\n\n**Scope 3: Catalog.** Let teams find and publish tools themselves, including on-premises ones. When tool registration requires tickets and on-prem systems stay excluded, deploy the Registry, Resources MCP, OPA, and per-tool cost attribution.\n\n**Scope 4: Harden.** Lock down the edge, watch everything, and plan for failure. When you reach over 1,000 users with no circuit breakers, public DNS, and no failover, add private connectivity, governance dashboards, deprecation workflows, and multi-Region failover.\n\nEach scope delivers standalone value. Advance only when the next pain appears. The following figure is a reference for scope decisions.\n\n## Solution walkthrough\n\nThe following sections build the gateway one scope at a time. Start with the prerequisites, then advance through each scope as new governance questions appear.\n\n### Prerequisites\n\nTo follow this post, you need an AWS account with permissions to create [Amazon Bedrock AgentCore](/bedrock/agentcore/) and [Amazon Cognito](/pm/cognito/) resources, familiarity with OAuth 2.0 and AWS Identity and Access Management (IAM), basic AWS Command Line Interface (AWS CLI) experience, and an understanding of the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/specification).\n\n### Scope 1: Connect, the minimal governed gateway\n\nThe following diagram illustrates the minimal topology for Scope 1:\n\n**When you need this scope**: 1–20 pilot users, low-risk tools, shadow MCP appearing.\n\n**Key decisions:** Gateway ownership (infrastructure engineering, security, or shared). First tool choice. Whether to mandate gateway-only or coexist with a legacy `mcp.json`\n\n.\n\n**What changes**\n\nYou stand up AgentCore Gateway with a Cognito-backed JWT authorizer and register one low-risk Lambda target (for example, a read-only ticket search). Authorization stays coarse: any authenticated client can invoke any registered tool. The `mcp.json`\n\ngains one new entry alongside existing public resources, emphasizing slow, additive change.\n\nYou can bring in your identity provider (IdP), for example Amazon Cognito, and integrate with AgentCore Identity, which handles [Machine-to-Machine (M2M) authentication](/blogs/mt/configuring-machine-to-machine-authentication-with-amazon-cognito-and-amazon-api-gateway-part-2/) through OAuth 2.0, outbound authentication of your AWS resources, or AWS Secrets Manager for API key-based auth. You now know when and which organizational resources were accessed through native [Amazon CloudWatch](/cloudwatch/) Logs and [AWS CloudTrail](/cloudtrail/).\n\n**Client flow**\n\n- The assistant bootstraps with a pre-provisioned client_id/client_secret and gateway URL.\n- Per session, it fetches a Cognito token and attaches the bearer to tools/list and tools/call.\n- The gateway validates the JWT and routes to the target.\n- Backend credentials never leave AWS.\n\n**Implementation snippets**.\n\nCreate the gateway with a JWT authorizer pointed at your IdP (for example, Cognito) and configure the allowedClients:\n\nThis command turns Cognito-issued JWTs into the gateway’s only accepted credential.\n\nThen register an AWS Lambda target (for example, a read-only ticket search):\n\nThe Lambda is now reachable as an MCP tool with no client-side wiring. A distributed `mcp.json`\n\nreplaces the local server entry:\n\nBecause the user base is small, distribute this entry to existing `mcp.json`\n\nfiles.\n\n**Rollout**\n\n**Phase 1 (day 1):** Provision a Cognito User Pool. Deploy the gateway. Register one low-risk Lambda target. **Phase 2 (day 2–3):** Distribute the updated `mcp.json`\n\nthrough MDM. Validate end-to-end: token fetch → tools/list → tools/call. **Phase 3 (week 1):** Confirm CloudWatch Logs and CloudTrail entries appear for each invocation.\n\n**Result**. The end-to-end path works, the `mcp.json`\n\nnow contains an endpoint that reaches org-wide resources, and executives observe that productivity and controls ship together.\n\nAfter this stage, if you start getting questions such as:\n\n- Are users passing any PII (personally identifiable information) through tool invocations? How are we preventing that?\n- Do we ask for users’ consent to perform actions on their behalf? How are we verifying accountability?\n- User groups should have different access to tools. Is that possible?\n\nThen you’re ready to expand the scope. If Scope 2 meets your current needs, skip to Considerations for operational guidance.\n\n### Scope 2: Control, identity-aware authorization and guardrails\n\nWith the door open, Scope 2 names the caller and scrubs what flows through.\n\nThe following diagram shows how identity, policy, and guardrails integrate in Scope 2:\n\n**When:** User base is growing and compliance asks “who did what, under which policy.” You need an answer, with PII scrubbed before it lands.\n\n**Key decisions:** Identity provider selection. Transition auth model (code flow compared to client credentials). LOG_ONLY duration before ENFORCE. First Cedar deny rule.\n\n**What changes**\n\nYou shift the gateway from machine-level trust to user-level trust. Clients now get dynamically added to the AgentCore Gateway allowedClients through a [Dynamic Client Registration (DCR)](https://www.runlayer.com/blog/what-is-dynamic-client-registration) mechanism. On the first tools/list call to the gateway, the client receives (RFC 9728/8414) metadata to call a DCR shim, which is a Lambda behind Amazon API Gateway that creates a Cognito app client on POST /register and appends the new client_id to AllowedClients through UpdateGateway.\n\nThe user signs in using SSO, completing the Authorization Code flow. Now the access token’s sub claim is the actual user. From here, every request carries that user identity. The first security gate, AgentCore Policy, intervenes where Cedar rules apply RBAC based on IdP group claims, token claims, and parameter gates. For example, `DeployCI___invoke`\n\ncan be restricted to `context.input.environment == \"staging\"`\n\n, allowing or forbidding access to certain users.\n\nIf allowed, AgentCore Policy evaluates the request through its native [Amazon Bedrock Guardrails](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html) integration, which applies PII filters, content policies, and prompt-attack detection at the gateway layer without custom code. For structural transforms or ABAC rules beyond what Guardrails covers, a request interceptor Lambda handles the remainder. When the target resource needs the user’s identity toward a SaaS system (for example, GitHub or Figma), AgentCore Identity Credential Providers handle the 3LO Authorization Code flow. The gateway emits an MCP elicitation (-32042 error) so the assistant can walk the user through consent in a browser.\n\nAt the response stage, interceptors scrub unintentional data. Every log record carries principal, matched policy ID, guardrail flag, and latency.\n\n**Client flow: M2M to user-delegated**.\n\n- The MCP client hits the gateway URL and receives a 401 with WWW-Authenticate.\n- It follows RFC\n[9728](https://datatracker.ietf.org/doc/html/rfc9728)/[8414](https://datatracker.ietf.org/doc/html/rfc8414)/[7591](https://datatracker.ietf.org/doc/html/rfc7591)discovery and calls your DCR shim to mint a user-scoped client. - The user signs in through Authorization Code + PKCE against hosted UI (backed by corporate SSO). The token’s sub claim is the actual user.\n- tools/list returns a catalog filtered by AgentCore Policy. Two users in different groups receive different tool lists.\n- Invocation flows: Policy, then Request Interceptor, then Guardrails, then target, then Response Interceptor, then Guardrails.\n- When a target needs the user’s identity for SaaS (GitHub, Slack), the gateway emits a -32042 elicitation with an authorization URL. For targets sharing the inbound identity chain, OBO token exchange replaces the browser redirect entirely. The assistant opens the browser, calls\n[CompleteResourceTokenAuth](https://docs.aws.amazon.com/bedrock-agentcore/latest/APIReference/API_CompleteResourceTokenAuth.html)on consent, and retries.\n\n**Implementation**\n\nAttach the policy engine in LOG_ONLY mode by using the `update-gateway`\n\ncommand.\n\nThe following Cedar policy combines RBAC and parameter-level ABAC:\n\n```\n// Payments deployers can deploy, but only to staging\npermit (\n  principal,\n  action == AgentCore::Action::\"DeployCI___invoke\",\n  resource\n)\nwhen {\n  principal.hasTag(\"groups\") &&\n  principal.getTag(\"groups\").contains(\"repo-payments-service\") /* Note: for Cognito, the claim is cognito:groups, not groups. Refer to your deployed Gateway Cedar schema for the precise tag names. */ &&\n  context.input.environment == \"staging\"\n};\n\n// Read-only tools are open to any authenticated principal with a group\npermit (\n  principal,\n  action in [\n    AgentCore::Action::\"TicketSearch___invoke\",\n    AgentCore::Action::\"DocsSearch___invoke\"\n  ],\n  resource\n) when { principal.hasTag(\"groups\") };\n```\n\nThe first rule pins risky deploys to staging. The second keeps low-risk reads frictionless. The following OpenTelemetry span attributes (emitted to the aws/spans log group) show a Deny decision:\n\nThat record is the audit trail your compliance team has been asking for.\n\nWith native Amazon Bedrock Guardrails integration in AgentCore Policy (shipped July 2026), guardrails are expressed directly inside Cedar policies using the suppressOutput effect and when guardrails condition. The interceptor-Lambda approach remains available for structural transforms that guardrails don’t cover. The following shows the native Cedar approach for PII filtering:\n\nSSNs and card numbers never reach the model. Emails are masked.\n\nDeploy the DCR shim: a Lambda behind Amazon API Gateway that creates Cognito app clients on POST /register and appends new client_id to allowedClients. Serve RFC 9728 .well-known/oauth-protected-resource metadata pointing to Cognito.\n\nCreate the 3LO credential provider and attach it to a target. The following is the minimal -32042 elicitation the client must handle:\n\nWhen the downstream resource trusts the same identity chain as the inbound token (for example, an internal microservice or a Microsoft Entra ID-protected API), the gateway can use [On-Behalf-Of (OBO) token exchange](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/on-behalf-of-token-exchange.html) instead. OBO exchanges the inbound access token for a new, scoped token that carries both the user’s identity and the agent’s identity, with no browser redirect and no additional consent flow. Add an `onBehalfOfTokenExchangeConfig`\n\nblock to the existing OAuth credential provider on the target, and the gateway handles the exchange transparently (RFC 8693 or RFC 7523 depending on your IdP).\n\n**Rollout**\n\n**Phase 1 (day 1–2):** Deploy the DCR shim Lambda and API Gateway endpoint. Update the gateway authorizer to accept dynamically registered clients. **Phase 2 (week 1–2):** Wire AgentCore Policy in LOG_ONLY mode. Deploy Guardrails in detect-only. Monitor aws.agentcore.policy.log_only_decision_flipping_policies to identify policies that would change decisions if promoted. **Phase 3 (week 3+):** Switch Policy to ENFORCE. Switch Guardrails to active blocking. Communicate the SSO consent prompt to users.\n\n**Result**. Auditors get answers: who called which tool, when, under which policy. PII gets scrubbed before the assistant receives responses.\n\nAfter this stage, if you start getting questions such as:\n\n- Are platform engineers buried under “please add this tool” tickets? Can users discover and subscribe to tools without filing one?\n- Do users need access to systems that don’t live on AWS, such as on-premises databases, another cloud, or external SaaS?\n- Can finance attribute gateway spend to the team that actually drove it?\n\nThen, you’re ready to expand the scope. If Scope 2 meets your current needs, skip to Considerations for operational guidance.\n\n### Scope 3: Catalog, self-service, registry, and cross-environment reach\n\nNow make it self-serve and reach systems off AWS.\n\nThe following diagram shows the expanded architecture for Scope 3, including cross-environment connectivity:\n\n**When:** “add this tool” tickets pile up, or you need reach into another vendor or on-premises. Past 100 users, central catalog and reach beyond AWS are not optional.\n\n**Key decisions:** Self-serve publishing with approval, or ticket-gated. First on-premises or multi-cloud target. OPA for org-wide policy rules, and sophisticated ABAC logic or Cedar only.\n\n**What changes**\n\nYou stop being the bottleneck for tool intake, and the gateway extends to systems outside AWS. Tool owners now create a YAML manifest to request new tools and open a pull request that triggers a security scan and platform review. On merge, your continuous integration pipeline calls create-gateway-target and updates the Cedar policy automatically. No ticket required, no manual UpdateGateway.\n\nYou can now centralize skills your IDE might need: it queries AWS Agent Registry (now in the `agent-registry`\n\nnamespace, available in nine AWS Regions) to list skills and download the ones relevant for the task. Administrators govern discoverability through an approval workflow, so people receive only what they need, keeping irrelevant skills out of the assistant’s context and reducing prompt pollution.\n\nWhen a request leaves the gateway, the target might live anywhere: AWS Lambda, an on-premises database that you reach through Gateway VPC Egress (using `managedVpcResource`\n\nor `selfManagedLatticeResource`\n\nconfigurations) with AWS Direct Connect or AWS Site-to-Site VPN behind it, or a SaaS API that you reach through NAT egress with outbound OAuth. The client cannot tell the difference.\n\nInside the request path, Open Policy Agent (OPA) evaluation is added inside the existing request-interceptor Lambda to cover rules Cedar can’t natively express: time windows, payload content inspection, rate-based access, and change-ticket requirements. A second MCP connection (the Resources MCP server) auto-fetches on session start and distributes organizational context such as steering files, coding standards, prompt templates, release checklists, and on-call runbooks. Every assistant in the org picks up the same context without per-developer config.\n\nFor FinOps, Amazon CloudWatch metric filters and AWS Cost Explorer tags attribute cost per tool and per group. Finance can finally answer who drove the bill. The `mcp.json`\n\nis now managed centrally, with no way to add your own public configurations, and it is distributed through MDM or a central MCP registry. In addition to the gateway, you also manage IDE admin configuration centrally, which controls behavior.\n\n**Client flow**. Bootstrap matches Scope 2, with no new auth flow. A second `mcp.json`\n\nentry for the Resources MCP server is auto-fetched on session start, providing organizational standards and approved skills. Invocation still goes through the gateway. The target might live on-premises or in SaaS, and the client can’t tell. Scope 3 is additive on the client side, making it a low-risk rollout.\n\n**Implementation snippets**.\n\nThe following OPA Rego policy handles a rule Cedar cannot natively express. `db_write`\n\nis allowed only on weekdays, 09:00 to 17:00 UTC, with a change ticket attached:\n\n``` python\npackage mcp.tools\n\nimport rego.v1\n\ndefault allow := false\n\nallow if {\n  input.tool == \"db_write\"\n  clock := time.clock(time.now_ns())\n  clock[0] >= 9\n  clock[0] < 17\n  weekday := time.weekday(time.now_ns())\n  not weekday in {\"Saturday\", \"Sunday\"}\n  input.claims.change_ticket_id != \"\"\n}\n```\n\nOPA handles clock and weekday checks natively, complementing Cedar’s identity and resource-based policies.\n\nThe following is a Registry YAML manifest for a new tool:\n\nTool ownership, access, and risk live in version control alongside the rest of your infrastructure. Your continuous integration pipeline validates the manifest, runs a security scan, opens a pull request for review, and on merge calls create-gateway-target and updates the Cedar policy.\n\nThe following Resources MCP server config is distributed to every assistant, exposing tools such as `get_coding_standards`\n\n, `get_prompt_library`\n\n, `get_release_checklist`\n\n, and `get_oncall_runbook`\n\n:\n\nEvery assistant in the org now accesses the same coding standards and runbooks without manual setup.\n\nThe following command creates a PrivateLink endpoint into the gateway from a virtual private cloud (VPC) that peers with on-premises through AWS Direct Connect:\n\nGateway traffic now stays on the AWS network. From there, AWS Direct Connect handles the on-premises hop. For non-MCP endpoints (A2A agent URLs, legacy REST APIs), HTTP passthrough targets route traffic directly without protocol translation.\n\nThe following AWS Budgets alert fires when a tool exceeds a monthly invocation-cost threshold:\n\nPer-tool tagging means finance can attribute spend to the team that owns the tool, not the platform.\n\n**Rollout**\n\n**Phase 1 (week 1):** Set up the YAML manifest schema and CI pipeline. Migrate existing targets to manifest-driven registration. **Phase 2 (week 2–3):** Deploy the OPA interceptor. Create the Resources MCP server. Establish PrivateLink or Direct Connect for on-premises targets. **Phase 3 (week 4+):** Configure cost allocation tags and Budgets alerts. Distribute the updated `mcp.json`\n\n. Roll out group by group, starting with teams that filed the most tool-request tickets.\n\n**Result**. The Scope 2 ticket-driven intake is eliminated. Natural-language discovery shortens onboarding, and the gateway reaches on-premises and multi-cloud without lifting workloads.\n\nAfter this stage, if you start getting questions such as:\n\n- Is your gateway still reachable from the public internet, and would a regulator be comfortable with that?\n- If your primary Region fails during business hours, what is the documented recovery path users would follow?\n- How many registered tools had zero invocations last quarter, and who is paying to keep them on the books?\n\nThen, you’re ready to expand the scope. If Scope 3 meets your current needs, skip to Considerations for operational guidance.\n\n### Scope 4: Harden, resilience and governance\n\nCatalog and reach are working. Scope 4 hardens the edge and plans for outages.\n\nThe following diagram shows the hardened architecture with private ingress and governance dashboards:\n\n**When**: AI workloads that require high availability and resilience, heavily regulated industries, or a global user base with low-latency and DR requirements.\n\n**Key decisions:** Circuit breaker blast radius. Active-active or active-passive DR. Gateway SLO target. Deprecation authority ownership.\n\n**What changes**\n\nYou harden the perimeter and turn governance into something a regulator can read at a glance. The request now starts inside your corporate network. Your IDE no longer resolves a public gateway hostname. Instead, it routes through Amazon CloudFront at the edge (close to users), which forwards to a CloudFront-restricted Application Load Balancer in a public subnet using a shared-secret header that prevents traffic from bypassing CloudFront. The request then moves through a VPC Endpoint in a private subnet to PrivateLink and finally the gateway. Public DNS exposure is gone, and the gateway is reachable only through your private path. For Runtime-hosted agents, enable inbound-only enforcement so the Runtime rejects any invocation that does not originate from the gateway. This prevents callers from bypassing policy, guardrails, and audit.\n\nThe request follows the same Scope 3 path, but now every decision flows into Amazon CloudWatch and AWS CloudTrail where [Amazon Athena](/athena/) queries answer compliance-grade questions. For example: “Which principals had the highest deny rate last week, and which policies denied them?” Custom dashboards surface invocations, latency percentiles, guardrail intervention rates, deny rate per policy, top-denied principals, and an executive compliance view with anomaly alerts.\n\nFor global users, Multi-AZ provides strong resilience within a Region. You extend with [Amazon Route 53](/route53/) health-checked failover and a multi-Region active-passive deployment where gateway definitions and registry state replicate through your pipelines. Design tools to be idempotent so the first retry after a DNS failover is safe.\n\nFinally, a nightly deprecation Lambda reads Amazon CloudWatch invocation metrics and opens a pull request for any tool with zero usage over 30 days. Owners are notified, the registry marks the tool, the policy moves to LOG_ONLY, and after 90 days the target is removed. Your gateway never accumulates zombies.\n\n**Client flow**. Auth and discovery stay unchanged from Scope 3. The assistant runs on the corporate network with a route to the gateway’s PrivateLink endpoint, and the hostname might resolve only on-network. With Route 53 failover, a failed request triggers DNS re-resolution and lands in the secondary Region. Clients now additionally handle Deprecation headers (RFC 8594) surfaced to the user, 429 with Retry-After for quota exhaustion, and optionally OpenTelemetry traces correlated through `traceparent`\n\nwith the gateway’s spans.\n\n**Implementation**.\n\nThe following Amazon Route 53 failover record set configures gateway endpoints in two Regions:\n\nWhen the primary health check fails, DNS switches to the secondary Region within one TTL.\n\nThe following Amazon Athena query over AWS CloudTrail answers “Which principals had the highest deny rate last week, and which policies denied them?”:\n\nThis CloudWatch Logs Insights query (run against the aws/spans log group with tracing enabled on the gateway) feeds the dashboard tile that surfaces drift before users start filing tickets.\n\nThe following AWS Cloud Development Kit (AWS CDK) snippet sets up the CloudFront, CloudFront-restricted Application Load Balancer, and VPC Endpoint stack:\n\nThe shared-secret header makes sure traffic only reaches the ALB through CloudFront, not through direct DNS.\n\nThe following nightly deprecation Lambda (pseudocode) reads Amazon CloudWatch metrics and opens a deprecation pull request:\n\nZombie tools get retired automatically through the same code-review process that created them.\n\n**Rollout**\n\n**Phase 1 (week 1–2):** Deploy CloudFront + ALB + VPC Endpoint stack. Update DNS. Validate public endpoint is no longer resolvable. **Phase 2 (week 3–4):** Deploy Athena tables and governance dashboard. Set up Route 53 health checks and failover records. Replicate gateway definitions to secondary Region. **Phase 3 (month 2):** Deploy the deprecation Lambda. Run a failover drill: disable the primary health check and validate DNS switches.\n\n**Result**. Zero-trust network controls, private connectivity, global low-latency access at the edge, and documented recovery paths. Governance becomes a visible product.\n\nThat covers the full four-scope build, but most teams don’t need every scope. The rest of this post helps you decide where to stop, provides a real-world example, and covers operational considerations.\n\n## Reference deployment timeline\n\nThe following timeline shows how a representative financial services organization walked these four scopes in six months.\n\n**Scope 1 (Week 1).** Two analysts ran Amazon Quick against a staging SQL tool. AgentCore Gateway fronted it with Cognito M2M auth. Infrastructure engineering owned the gateway from day one.\n\n**Scope 2 (Weeks 2–4).** Thirty analysts across three desks. DCR shim, Authorization Code + PKCE, desk-level RBAC, Guardrails for PII, CloudTrail. Switching auth flows mid-rollout was awkward. Compliance’s first audit query returned complete results on the first attempt.\n\n**Scope 3 (Months 2–3).** Two hundred users across five departments. The Registry made tools discoverable. Trading stayed on-premises through Direct Connect. Resources MCP distributed checklists. The ticket queue dropped about 40 percent in two weeks.\n\n**Scope 4 (Month 6).** Bank-wide, 1,000 users. MiFID II required immutable audit and network isolation. PrivateLink removed public DNS. Route 53 failover met the 4-hour RTO.\n\n**Outcome.** Regulators could trace which analyst queried which positions, under which policy. The graduation trigger for each scope was a concrete organizational question, not a predetermined timeline.\n\n## Considerations\n\nThese considerations cut across every scope. Note that Amazon Bedrock AgentCore Gateway and Amazon Bedrock Guardrails availability varies by AWS Region. See the [Amazon Bedrock AgentCore documentation](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/) for current Region support.\n\n**Gateway operations**. Treat the gateway with operational practices equivalent to your production services from day one. Later changes cost more. Run dev, staging, and production across separate AWS accounts, IdP client IDs, and policy engines, promoted through IaC. Choose one org-wide gateway or per-BU for isolation. Enforce naming at intake. Evaluate new tools on risk tier, data classification, owner SLA, and auth-model fit. Registration flow: request, review, scan, staging, soak, production.\n\n**Security**. Plaintext credentials and unscoped egress create opportunities for inadvertent access. Store credentials in AWS Secrets Manager or HashiCorp Vault with rotation, or eliminate shared secrets entirely by using Private Key JWT client authentication (private key in AWS KMS, every signing operation recorded in CloudTrail). Never store credentials in environment variables. Distribute a centrally managed `mcp.json`\n\nthrough MDM. Block assistant traffic to non-gateway MCP endpoints at the corporate proxy or endpoint detection and response (EDR). Require TLS 1.2+ and AWS Key Management Service (AWS KMS) encryption at rest. Apply AWS IAM Service Control Policies (SCPs) with `aws:CalledViaAWSMCP`\n\nor `aws:ViaAWSMCPService`\n\nto deny destructive operations invoked through AWS-managed MCP servers (these keys don’t apply to traffic through your own AgentCore Gateway. For your own gateway, restrict the target execution role instead):\n\nIf a Cedar policy slips through review, the SCP backstop blocks the worst outcomes.\n\n**Resilience**. When the gateway is down, all assistants relying on it are unavailable. Every gateway, target, policy, and registry entry ships as code. Federated regional gateways cover data residency (EU, China, Russia). Replicate *policy*, not *data*. One gateway serves Kiro, Claude Code, Amazon Quick, and Glean.\n\n**Cost**. Cost surprises arrive faster than usage reports. Rate-limit per principal and per tool (natively supported by Gateway configurable rate limiting at no extra charge, with dimensional scoping by JWT claims, targets, and tool names). Set budgets and quotas per group with soft alerts before hard stops. Cache responses for idempotent read tools at the interceptor to reduce redundant invocations. For reference pricing, about 50 developers running 572,000 operations in total per month cost approximately $17 for Gateway and Policy combined (Gateway InvokeTool at $5 per million plus Policy authorization at $25 per million; Identity costs $0 when consumed through Gateway) (refer to the [Amazon Bedrock AgentCore pricing page](/bedrock/agentcore/pricing/) for current rates).\n\n## Clean up resources\n\nIf you deployed resources while following this post, remove them to avoid ongoing charges. Delete resources in reverse order of creation to avoid dependency errors.\n\n**Scope 4 resources**:\n\n- Delete the Amazon Route 53 failover records and health checks.\n- Delete the CloudFront distribution.\n- Delete the Application Load Balancer, target group, and associated security groups.\n- Delete the VPC Endpoint for\n`bedrock-agentcore`\n\n. - Remove the deprecation Lambda and its CloudWatch Events rule.\n- Drop the Amazon Athena tables and workgroup.\n\n**Scope 3 resources**:\n\n- Delete AWS Budgets alerts and cost allocation tags.\n- Remove the PrivateLink VPC Endpoint for on-premises connectivity.\n- Delete the Resources MCP server target from the gateway.\n- Remove registered tool targets created from YAML manifests.\n- Delete the OPA interceptor Lambda.\n\n**Scope 2 resources**:\n\n- Delete the Guardrails configuration.\n- Delete the Request and Response Interceptor Lambdas.\n- Delete the DCR shim Lambda and its Amazon API Gateway endpoint.\n- Remove Cedar policies from AgentCore Policy.\n- Delete the DynamoDB table used for ABAC rules.\n\n**Scope 1 resources**:\n\n- Delete gateway targets (for example, TicketSearch) using\n[DeleteGatewayTarget](https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_DeleteGatewayTarget.html). - Delete the gateway itself:\n`aws bedrock-agentcore-control delete-gateway --gateway-identifier pilot-gateway`\n\n(see[DeleteGateway](https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_DeleteGateway.html)). - Delete the Cognito User Pool app client and, if created for this purpose, the User Pool.\n- Delete the IAM role used by the gateway (\n`GatewayRole`\n\n).\n\n## Continuous improvement\n\nGovernance is a living system.\n\n**Quarterly**. Review deny logs and adjust policies to tighten overly permissive rules and relax those that create friction without reducing risk. Audit PrivateLink endpoints and egress rules. Remove anything unused. Narrow gateway execution roles. Keep Resources MCP content fresh and version steering files. Enforce the deprecation mechanism so your registry has zero zombie tools.\n\n**Monthly**. Review cost anomalies, guardrail intervention spikes, and top-denied principals. A top-denied principal often signals that the policy is too tight.\n\n**Continuously**. Every tool registration and policy change ships as a pull request reviewed by security and platform groups.\n\n## Conclusion\n\nIn this post, we walked through a four-scope maturity model for governing AI agent tool access, from a single governed endpoint to enterprise-wide hardening. With this approach, teams ship AI productivity and governance controls together, advancing only when real pain demands it.\n\nIf you’re getting started, stand up a Scope 1 gateway in a development account, point one assistant at it, and distribute the new `mcp.json`\n\n.\n\nIf you need compliance, start with Scope 1 as the foundation (it takes a day), then layer Scope 2: add the DCR shim, wire Cedar in LOG_ONLY, and enable Guardrails in detect-only mode. The two scopes deploy together within a sprint.\n\nIf you are scaling production, Scope 3’s registry and self-serve publishing deliver the immediate user-visible gains. Per-tool tagging gives finance attribution. Roll out group by group.\n\nAs IDE-driven assistants mature, the same gateway becomes the control plane for autonomous agents. The gateway provides not only tool access but also agent-to-agent task delegation, with every invocation flowing through policy.\n\nPick the scope that matches today’s pain and use the [Amazon Bedrock AgentCore Gateway developer guide](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html) to deploy your first gateway. Start with a single low-risk tool behind the gateway, validate the end-to-end token flow with your identity provider, and expand scope only when you encounter the next governance question from your team.\n\nThis guide shows you a sample implementation of how to build a [governance layer and a tools gateway using AgentCore Gateway](https://github.com/aws-samples/sample-ai-agent-factory/tree/main/enterprise-mcp-governance-gateway).\n\n### Further reading\n\n- Read the\n[Amazon Bedrock AgentCore Gateway documentation](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html). - Review the\n[Model Context Protocol specification](https://modelcontextprotocol.io/specification). - Read\n[Govern MCP tools at scale with Kiro and AgentCore Gateway](https://builder.aws.com/content/3CS1jTWHngGW3IxFXCjcP2T9l8B/govern-mcp-tools-at-scale-with-kiro-and-agentcore-gateway)on builder.aws.com. - Review the\n[Open Policy Agent and Rego documentation](https://www.openpolicyagent.org/docs/policy-language/)for self-hosted policy. - Review the\n[NeMo Guardrails project](https://github.com/NVIDIA/NeMo-Guardrails)for self-hosted guardrails. - Review the\n[LangFuse documentation](https://langfuse.com/docs)for self-hosted observability. - Explore\n[Amazon Bedrock AgentCore](https://console.aws.amazon.com/bedrock/)in the AWS Management Console. - Read\n[Introducing Amazon Bedrock AgentCore Gateway](/blogs/machine-learning/introducing-amazon-bedrock-agentcore-gateway-transforming-enterprise-ai-agent-tool-development/)for the service launch announcement.", "url": "https://wpnews.pro/news/govern-ai-agent-tool-access-with-amazon-bedrock-agentcore-gateway", "canonical_source": "https://aws.amazon.com/blogs/machine-learning/govern-ai-agent-tool-access-with-amazon-bedrock-agentcore-gateway/", "published_at": "2026-08-21 17:02:35+00:00", "updated_at": "2026-08-21 17:13:55.893126+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-policy", "ai-infrastructure"], "entities": ["Amazon Web Services", "Amazon Bedrock AgentCore", "AgentCore Gateway", "AgentCore Identity", "AgentCore Policy", "Amazon Bedrock Guardrails", "AWS Agent Registry", "Kiro"], "alternates": {"html": "https://wpnews.pro/news/govern-ai-agent-tool-access-with-amazon-bedrock-agentcore-gateway", "markdown": "https://wpnews.pro/news/govern-ai-agent-tool-access-with-amazon-bedrock-agentcore-gateway.md", "text": "https://wpnews.pro/news/govern-ai-agent-tool-access-with-amazon-bedrock-agentcore-gateway.txt", "jsonld": "https://wpnews.pro/news/govern-ai-agent-tool-access-with-amazon-bedrock-agentcore-gateway.jsonld"}}