翻訳待ち：Govern AI agent tool access with Amazon Bedrock AgentCore Gateway

AI サービスが一時的に利用できないため、復旧後に翻訳を補完します。

In 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. When 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 containing 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. The proposed solution uses Model Context Protocol (MCP)-enabled assistants, including IDE helpers like Kiro, Claude Code, Cursor, and AI tools like Amazon 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 (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 (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. You can then augment the policy with safety and privacy controls using Amazon Bedrock Guardrails, and build a centralized catalog for organizing, curating, and discovering tools using AWS Agent Registry. Self-hosted options (Kong Gateway, Open Policy Agent, NeMo Guardrails, and LangFuse) also exist, and this post calls them out where relevant. The problem There 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). Take policy drift as an example. Each AI assistant carries its own mcp.json, 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. Recall 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. The solution: a four-scope maturity journey A 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. 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. 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. 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. 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. Each scope delivers standalone value. Advance only when the next pain appears. The following figure is a reference for scope decisions. Figure 1: Reference for choosing a scope based on the governance pain point you face Solution walkthrough The following sections build the gateway one scope at a time. Start with the prerequisites, then advance through each scope as new governance questions appear. Prerequisites To follow this post, you need an AWS account with permissions to create Amazon Bedrock AgentCore and Amazon 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). Scope 1: Connect, the minimal governed gateway The following diagram illustrates the minimal topology for Scope 1: Figure 2: MCP clients connect to AgentCore Gateway, Amazon Cognito issues JWTs for authentication, AgentCore Identity manages outbound credentials, and one registered target receives tool calls When you need this scope: 1–20 pilot users, low-risk tools, shadow MCP appearing. Key decisions: Gateway ownership (infrastructure engineering, security, or shared). First tool choice. Whether to mandate gateway-only or coexist with a legacy mcp.json. What changes You 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 gains one new entry alongside existing public resources, emphasizing slow, additive change. You can bring in your identity provider (IdP), for example Amazon Cognito, and integrate with AgentCore Identity, which handles Machine-to-Machine (M2M) authentication 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 Logs and AWS CloudTrail. Client flow The assistant bootstraps with a pre-provisioned client_id/client_secret and gateway URL. Per session, it fetches a Cognito token and attaches the bearer to tools/list and tools/call. The gateway validates the JWT and routes to the target. Backend credentials never leave AWS. Implementation snippets. Create the gateway with a JWT authorizer pointed at your IdP (for example, Cognito) and configure the allowedClients: aws bedrock-agentcore-control create-gateway \ --name pilot-gateway \ --role-arn arn:aws:iam:::role/GatewayRole \ --protocol-type MCP \ --authorizer-type CUSTOM_JWT \ --authorizer-configuration '{ "customJWTAuthorizer": { "discoveryUrl": "https://cognito-idp..amazonaws.com//.well-known/openid-configuration", "allowedClients": ["pilot-gateway-client"] } }' This command turns Cognito-issued JWTs into the gateway’s only accepted credential. Then register an AWS Lambda target (for example, a read-only ticket search): aws bedrock-agentcore-control create-gateway-target \ --gateway-identifier pilot-gateway \ --name TicketSearch \ --target-configuration '{ "mcp": { "lambda": { "lambdaArn": "arn:aws:lambda:::function:ticket-search", "toolSchema": {"inlinePayload": ""} } } }' The Lambda is now reachable as an MCP tool with no client-side wiring. A distributed mcp.json replaces the local server entry: { "mcpServers": { "enterprise-tools-gateway": { "url": "https://.gateway.bedrock-agentcore..amazonaws.com/mcp", "type": "http" } } } Because the user base is small, distribute this entry to existing mcp.json files. Rollout 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 through 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. Result. The end-to-end path works, the mcp.json now contains an endpoint that reaches org-wide resources, and executives observe that productivity and controls ship together. After this stage, if you start getting questions such as: Are users passing any PII (personally identifiable information) through tool invocations? How are we preventing that? Do we ask for users’ consent to perform actions on their behalf? How are we verifying accountability? User groups should have different access to tools. Is that possible? Then you’re ready to expand the scope. If Scope 2 meets your current needs, skip to Considerations for operational guidance. Scope 2: Control, identity-aware authorization and guardrails With the door open, Scope 2 names the caller and scrubs what flows through. The following diagram shows how identity, policy, and guardrails integrate in Scope 2: Figure 3: Gateway, Identity, and Policy bracketed by request and response interceptors with Amazon Bedrock Guardrails; Identity adds a DCR interface (Lambda and Amazon API Gateway for .well-known endpoints), AWS IAM, and Amazon DynamoDB, and a 3LO elicitation redirects users to the browser for consent When: User base is growing and compliance asks “who did what, under which policy.” You need an answer, with PII scrubbed before it lands. Key decisions: Identity provider selection. Transition auth model (code flow compared to client credentials). LOG_ONLY duration before ENFORCE. First Cedar deny rule. What changes You 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) 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. The 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 can be restricted to context.input.environment == "staging", allowing or forbidding access to certain users. If allowed, AgentCore Policy evaluates the request through its native Amazon Bedrock Guardrails 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. At the response stage, interceptors scrub unintentional data. Every log record carries principal, matched policy ID, guardrail flag, and latency. Client flow: M2M to user-delegated. The MCP client hits the gateway URL and receives a 401 with WWW-Authenticate. It follows RFC 9728 / 8414 / 7591 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. tools/list retur [truncated for AI cost control]