AWS Wants One Gatekeeper Between AI Agents and Company Tools

AgentCore Gateway is designed to move agent access out of scattered local configurations and into a centrally governed endpoint. The hard part is not connecting the first tool; it is deciding when a pilot needs user-level permissions, consent, data filtering and failure controls.

By 3 min read
AWS Wants One Gatekeeper Between AI Agents and Company Tools
AWS Wants One Gatekeeper Between AI Agents and Company Tools

Listen to this story

The audio brief

About 1:37
0:001:37
Read transcript
AWS is proposing one front door for AI agents that need to use company tools: Amazon Bedrock AgentCore Gateway. Instead of letting every assistant carry its own mcp.json file, backend credentials, and tool endpoints, the gateway would centralize access, identity, policy, and auditing around the Model Context Protocol, or MCP. The first rollout stage, Connect, is designed for pilots with one to twenty users and relatively low-risk tools. A client sends a Cognito-backed JSON Web Token with a tool request. The gateway validates it, routes the call to a registered target, and keeps the backend credentials inside AWS. CloudWatch Logs and CloudTrail provide the audit trail. The more consequential shift comes with Control. Access can move from machine-level trust to individual users, using identity groups, token claims, and request parameters. AgentCore Policy could allow a deployment only when its environment is staging. Bedrock Guardrails can add personally identifiable information filtering, content policies, and prompt-attack detection. If a SaaS tool needs the user’s identity, AgentCore Identity can send that user through a browser-based consent flow. Catalog is meant to make tools discoverable through a central Agent Registry, while Harden targets deployments above one thousand users, with private connectivity and multi-Region failover. AWS is leaving the rollout deliberately incremental. The key constraint is organizational: who owns the gateway, which legacy configurations can coexist, and when a log-only policy becomes a real deny rule.

Story brief

3 key points

AWS is positioning Amazon Bedrock AgentCore Gateway as an enterprise control plane for MCP-based agent tool access, keeping backend credentials in AWS instead of individual client configurations. Its staged rollout starts with Connect for 1–20 users and low-risk tools, then adds user-level authorization, policy enforcement, guardrails, tool catalogs, and hardened infrastructure for deployments exceeding 1,000 users....

  1. 01

    Connect targets pilots of 1–20 users, using Cognito JWTs plus CloudWatch Logs and CloudTrail auditing.

  2. 02

    Control can bind access tokens to individual users and tailor tool lists using identity groups, claims and request parameters.

  3. 03

    AgentCore Policy can restrict actions by parameters, such as allowing deployments only to staging environments.

AI assistants that can search tickets, query databases or trigger deployments create a security problem beyond the model prompt: organizations need to know which agent reached which tool, under whose authority, and with what credentials. AWS is pitching Amazon Bedrock AgentCore Gateway as a single governed entry point for that traffic, built around the Model Context Protocol, or MCP.

The immediate target is a familiar deployment pattern: an assistant’s local mcp.json configuration can hold backend credentials and tool endpoints. AWS identifies credential sprawl, policy drift, audit gaps, cost opacity and unreviewed integrations as structural problems in enterprise MCP deployments. Its answer is to put the connection behind a gateway, rather than leave every client to carry its own configuration and secrets.

AWS’s first stage, Connect, is aimed at 1 to 20 pilot users, low-risk tools and emerging shadow MCP use. It pairs a Cognito-backed JWT authorizer with centralized credentials and CloudWatch Logs and CloudTrail auditing. In the proposed setup, an MCP client obtains a token, sends it with tool requests, and the gateway validates the token before routing the call to a registered target; backend credentials remain in AWS.

The second stage, Control, moves from machine-level trust to user-level trust. Dynamic client registration and an authorization-code sign-in flow can put the actual user in the access token’s subject claim. The gateway can then return different tool lists to users in different groups, while AgentCore Policy applies Cedar rules based on identity-provider groups, token claims and request parameters.

The controls AWS layers on after the initial connection

  • Tool and parameter authorization: a policy can allow a deployment action only when its environment parameter is staging.
  • Data and prompt controls: Bedrock Guardrails can apply personally identifiable information filtering, content policies and prompt-attack detection at the gateway layer.
  • Delegated access: when a SaaS target needs a user identity, AgentCore Identity can direct the user through a browser-based consent flow.
  • Decision records: AWS says its logs can carry the principal, matched policy ID, guardrail flag and latency for each request.

AWS frames Catalog as the point where teams need to discover and publish tools without tickets, including on-premises tools. Its Agent Registry is the proposed centralized catalog. Harden is intended for deployments past 1,000 users that need private connectivity, governance dashboards, deprecation workflows and multi-Region failover.

The design is explicitly incremental: AWS recommends advancing from Connect through Control, Catalog and Harden only when the next operational pain appears. That leaves enterprises with consequential choices of their own, including who owns the gateway, whether old local mcp.json entries may coexist, how long policies run in log-only mode, and which first deny rule is appropriate. The centralization is the mechanism; the permission model and rollout discipline remain the deployment test.

Sources

  1. aws.amazon.comGovern AI agent tool access with Amazon Bedrock AgentCore Gateway | Amazon Web Services

Loading discussion...