AWS Builder Center

Govern MCP Tools at Scale with Kiro and AgentCore Gateway

Learn to govern MCP tools at scale using Kiro and Amazon Bedrock AgentCore Gateway with identity-aware authentication and Cedar policy enforcement.

Sr. Solutions Architect, AWS
Updated May 1, 2026 — this post reflects recent Amazon Bedrock AgentCore releases:  AWS Agent Registry  (April 2026) for centralized MCP server and tool discovery, and AgentCore Identity  On-Behalf-Of (OBO) token exchange , now generally available across 14 AWS Regions (April 2026). This post also notes the availability of  AgentCore Gateway VPC private access  for reaching resources in customer VPCs and on-premises environments without public internet exposure.

TL;DR

This post outlines a governance pattern designed to help organizations meet security and compliance requirements by standardizing Model Context Protocol (MCP) server consumption through a centrally managed registry and enforcing administrator-defined, fine-grained authorization over tool usage within those MCP servers.
The pattern combines:
  •  Kiro IDE  – used by developers to consume MCP servers.
Amazon Bedrock AgentCore provides three key capabilities used in this architecture:
In this post, you will learn to:
  • Configure AgentCore Gateway with OIDC-based inbound authentication.
  • Register internal and external MCP tool targets behind the Gateway.
  • Define Cedar policies for tool-level and parameter-level authorization.
  • Set up a centralized MCP registry for Kiro IDE.
  • Monitor and audit MCP tool usage.

AgentCore Gateway

Serves as the centralized MCP endpoint. It exposes approved application programming interfaces (APIs) and services as MCP tools and is designed to evaluate each tool invocation before forwarding it to the underlying target.

AgentCore Identity

Manages both inbound and outbound authentication for the Gateway. For inbound requests, Identity validates developer credentials via OIDC or  AWS Identity and Access Management (IAM)  and attaches identity context for the policy engine. For outbound requests, Identity vends short-lived, scoped credentials per request when the Gateway reaches downstream targets such as Slack or a database. It handles OAuth 2.0 (an industry-standard authorization protocol) flows and token rotation automatically.

Gateway Policy Engine (Cedar, an open-source policy language for fine-grained authorization)

Uses Cedar-based policies to control access at the tool and parameter level, enabling administrators to define which tools can be invoked and under what conditions. Supports natural-language-to-Cedar policy generation and two enforcement modes: LOG_ONLY (audit without blocking) and ENFORCE (active blocking).
Start with LOG_ONLY mode, validate policy decisions via logs, and switch to ENFORCE once policies are stable.

The governance challenge

As MCP adoption grows, developer IDEs can connect to external MCP servers that expose tools and data directly to AI agents. While this increases productivity, it requires governance controls:
  • Organizations need visibility into which external tools access sensitive systems
  • Organizations need centralized authorization controls for tool invocations
  • A gateway provides centralized control over MCP requests and responses, enabling organizations to enforce content filtering and inspect data in transit
  • Organizations need policy enforcement independent of application logic
To address this, organizations need:
  1. Centralized MCP server discovery
  1. Identity-aware authentication
  1. Policy-based, tool-level authorization
  1. Central auditability

Architecture overview


  1. AgentCore Gateway acts as the single MCP endpoint for all developer workstations, enforced by corporate network or DNS policy. Behind the Gateway, registered targets map to internal services and external MCP servers.
  1. Gateway inbound authentication verifies the developer's identity (via an OIDC JSON Web Token (JWT) or IAM) so that requests to the Gateway carry a validated identity context.
  1. Gateway outbound authentication uses AgentCore Identity to authenticate calls from the Gateway to downstream MCP targets, propagating the developer’s identity from the inbound request. For example, when a developer invokes a “query-customer-db” tool, the Gateway forwards their validated identity to the database service — so the service can enforce row-level access (an EU-support engineer sees only EU records) instead of granting blanket Gateway-level access.
  1. AgentCore Policy runs at the Gateway and enforces which tools and inputs each principal (developer, agent, role) may invoke.
  1. Central MCP registry and distribution: Kiro enterprise MCP registry delivers the approved server list to each developer’s IDE. The registry points exclusively to the AgentCore Gateway endpoint, which helps prevent developers from adding unapproved servers.

Benefits of this approach

  • Single network endpoint: Corporate network-level controls (DNS policies, firewall rules at the network perimeter) are the primary enforcement mechanism, preventing developers from bypassing governance. Kiro centralized MCP registry complements this by controlling which servers developers discover through the IDE.
  • Tools-as-first-class resources: AgentCore Gateway converts APIs and  AWS Lambda  functions into MCP-compatible tools and publishes metadata the Gateway enforces. This lets you reason about “tool = resource” for policy authors.
  • Policy at the boundary: AgentCore Policy deterministically allows/denies tool invocations before they reach your internal systems—no reliance on agent behavior.
  • Semantic tool discovery: The Gateway search-tools API enables agents to discover relevant tools from large catalogs without loading full metadata into the prompt, which can help reduce context consumption and may improve tool selection accuracy.

Implementation: step-by-step

The following steps walk through configuring each component of the governance architecture.

Prerequisites

Estimated time: 2–3 hours. Skill level: intermediate (familiarity with IAM, authentication protocols, and policy management).
Before you begin, verify that you have the following:
  • An AWS account with permissions to create AgentCore Gateway resources, IAM roles, and  Amazon CloudWatch  resources (for example, bedrock-agentcore:CreateGateway, bedrock-agentcore:CreateGatewayTarget, iam:CreateRole, logs:CreateLogGroup).
  • Kiro IDE installed (version 0.11.28 or later for enterprise registry support).
  • Basic familiarity with Cedar policy language and MCP concepts.
Important: Following this pattern creates AWS resources that incur charges. See the Cost estimation section for details.

Step 1 — Create AgentCore Gateway with inbound authentication

Wire your corporate single sign-on (SSO) via OIDC (IAM Identity Center,  Cognito , or another compatible identity provider (IdP)) so that only authenticated developers can reach the Gateway.

Design goals

  1. Authenticate each developer before allowing MCP requests to the Gateway.
  1. Map SSO attributes → AgentCore principals (user, groups, roles) used by the policy engine.
  1. Use short-lived tokens (OIDC JSON Web Token (JWT) or similar) so identity is fresh and revocable.
  1. Log authentication events for audit and compliance.

How it fits in the flow

  1. Developer opens Kiro and requests to use an MCP tool through the Gateway unified tool catalog.
  1. Kiro IDE performs SSO/OIDC authentication (or uses platform SSO integration) and obtains an identity token.
  1. The IDE uses that token when calling the AgentCore Gateway endpoint.
  1. AgentCore Identity validates the token, resolves principal attributes (username, groups, roles), and attaches a principal context to the request.
  1. AgentCore Policy evaluates the request against Cedar policies using the resolved principal and input context.
  1. Gateway forwards the call only if allowed.

Configuration steps

  1. Choose an IdP — Use your enterprise IdP (IAM Identity Center, Okta, Azure AD) supporting OIDC. Security Assertion Markup Language (SAML) is not directly supported; IdPs that use SAML internally can expose an OIDC endpoint**.**
  1. Register the Gateway as a relying party or client in your IdP (OIDC client).
  • Configure redirect URIs and allowed audiences.
  1. Configure AgentCore Identity to trust the IdP:
  • Configure the OIDC discovery URL (.well-known/openid-configuration endpoint) in the Gateway Custom JWT authorizer configuration.
  • Configure accepted audiences and token lifetimes.
  1. Map IdP claims to AgentCore principal attributes:
  • IdP claim email → principal.username
  • IdP claim groups → principal tag "groups" (via hasTag/getTag)
  • IdP claim job_title → principal.jobTitle (optional for attribute-based rules)
These mapped attributes are what Cedar policies reference (for example, principal.getTag("groups").contains("dev-team-a")).
  1. Enable token introspection / revocation checks (if supported) or use short lifetimes plus refresh flows.
  1. Enforce transport security — require HTTPS/TLS mutual-auth if policy requires additional assurance.
  1. Test using non-privileged and privileged accounts to verify mapping and policy enforcement.
After completing these steps, your AgentCore Gateway is configured with inbound authentication and ready to validate developer identities. See Verify your implementation for confirmation commands.
Example of Gateway creation with OIDC authorizer and policy engine:
Bash
aws bedrock-agentcore-control create-gateway \
--name company-gateway \
--role-arn arn:aws:iam::123456789012:role/GatewayRole \
--protocol-type MCP \
--authorizer-type CUSTOM_JWT \
--authorizer-configuration '{
"customJWTAuthorizer": {
"discoveryUrl": "https://idp.company.internal/.well-known/openid-configuration",
"allowedAudience": ["agentcore-gateway-client"],
"allowedClients": ["agentcore-gateway-client"],
"allowedScopes": ["bedrock:invoke"],
"customClaims": [
{
"inboundTokenClaimName": "groups",
"inboundTokenClaimValueType": "STRING_ARRAY",
"authorizingClaimMatchValue": {
"claimMatchValue": {
"matchValueStringList": ["dev-team-a", "docs-team"]
},
"claimMatchOperator": "CONTAINS_ANY"
}
}
]
}
}' \
--policy-engine-configuration '{
"arn": "arn:aws:bedrock-agentcore:us-west-2:123456789012:policy-engine/PlatformPolicyEngine-abc123",
"mode": "LOG_ONLY"
}'
> Note: Store the actual config in your platform account (AgentCore control plane) and keep secrets/certs in a secured parameter store.

Securing outbound communication with AgentCore Identity

When the Gateway calls an external MCP server — for example, a Slack workspace or a MySQL database — it must authenticate using the developer’s own credentials, not a shared service account. This preserves the same granular, per-user access control that the target system enforces for direct connections: a developer who can only read from a specific Slack channel or query certain database tables retains exactly those permissions when working through the Gateway.
AgentCore Identity makes this possible through On-Behalf-Of (OBO) token exchange — converting the inbound developer identity token into a scoped-down outbound credential that carries both the original user identity and the agent identity, granting just-in-time, least-privilege access without a second consent prompt. It vends short-lived, scoped credentials per request and manages OAuth 2.0 flows, token refresh, and rotation automatically. Developers and agents never hold long-lived secrets for external services.

Step 2 — Register tool targets (internal and external)

Register all MCP tools, internal or external, as targets behind AgentCore Gateway so that identity, policy, and audit are consistently applied.

Exposing internal services as MCP tools

Internal services can be registered as Gateway targets directly or through a Lambda function. The following example registers a PostgreSQL MCP server connected to an  Amazon Aurora  database, running inside the  Amazon Virtual Private Cloud (Amazon VPC) .
For the AgentCore Gateway to reach a private endpoint such as postgres-mcp.internal, configure VPC connectivity on the Gateway target. AgentCore Gateway supports two modes: a managed VPC resource mode in which AgentCore provisions the network path, and a self-managed mode in which you maintain the underlying AWS VPC Lattice Resource Gateway. For configuration details, see  Configuring Amazon Bedrock AgentCore Gateway for secure access to private resources  on the AWS Machine Learning Blog.
Example: Registering an Aurora PostgreSQL MCP server as a Gateway target
Bash
aws bedrock-agentcore-control create-gateway-target \
--gateway-identifier company-gateway \
--name AuroraQueryTool \
--target-configuration '{
"mcp": {
"mcpServer": {
"endpoint": "https://postgres-mcp.internal:8080/mcp"
}
}
}'
For use cases requiring custom logic — such as query filtering, input sanitization, or result transformation — wrap the database access in a Lambda function and register the Lambda ARN as the target instead.
After registration:
  • The tool becomes discoverable through the central MCP registry
  • The Gateway is designed to authenticate and evaluate each invocation against AgentCore Policy
  • Calls are logged for audit

Governing external MCP servers via AgentCore Gateway

Organizations may also need to govern third-party MCP servers (for example, Slack or documentation tools) through the Gateway. There are two alternative approaches.

Option A — Proxy the external MCP server behind Gateway

If the external MCP server runs within your network (for example, a self-hosted Slack MCP server inside an Amazon VPC), register the endpoint as a Gateway target — the same pattern used for internal services. If the MCP server is hosted outside AWS, configure secured egress (AgentCore Gateway VPC private access, Amazon VPC endpoints, or a network address translation (NAT) gateway) and use AgentCore Identity for outbound authentication. In both cases, the Gateway provides request and response inspection at the boundary.
Example:
Bash
aws bedrock-agentcore-control create-gateway-target \
--gateway-identifier company-gateway \
--name ExternalDocsTool \
--target-configuration '{
"mcp": {
"mcpServer": {
"endpoint": "https://external-docs.internal/mcp"
}
}
}'

Option B — Wrap with a Lambda function

Same as Option A but with a Lambda function in the middle for input validation, response filtering, or data transformation. The IAM execution role for the Lambda function must include permissions for the external endpoint. Configure AgentCore Identity to inject short-lived credentials at invocation time.
Example:
Bash
# Option B example: Lambda wrapper for external Jira API
# The Lambda handles authentication, input validation,
# and response filtering before returning results.
aws bedrock-agentcore-control create-gateway-target \
--gateway-identifier company-gateway \
--name JiraIssueLookup \
--target-configuration '{
"mcp": {
"lambda": {
"lambdaArn": "arn:aws:lambda:us-west-2:123456789012:function:jira-issue-lookup"
}
}
}'

Step 3 — Define Cedar access policies

AgentCore Policy is designed to evaluate each tool invocation at the Gateway boundary, regardless of whether a tool is internal or external.
Cedar uses a default-deny model: unless a permit policy explicitly allows an action, the request is denied. Policies operate on the authenticated principal, the requested action, the target resource, and the invocation context (input parameters).

Example governance requirement

Assume the following tools are registered behind AgentCore Gateway:
  • DeployCI (internal tool implemented with Lambda)
  • ExternalDocsTool (proxied third-party MCP server)
Enforce the following requirements:
  1. Members of dev-team-a can invoke DeployCI, but only when environment == "staging"
  1. Members of docs-team can invoke ExternalDocsTool
  1. All other invocations are denied by default

Example Cedar policy

cedar
// Cedar policy: tool-level access control with parameter conditions.
// Default-deny: only invocations matching a permit statement are allowed.
permit (
principal,
action,
resource
)
when {
// Scope to this Gateway instance
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/company-gateway"
&&
principal.hasTag("groups")
&&
(
(
// dev-team-a can deploy, but only to staging
action == AgentCore::Action::"DeployCI___invoke"
&&
principal.getTag("groups").contains("dev-team-a")
&&
context.input.environment == "staging"
)
||
(
// docs-team can use external documentation tool
action == AgentCore::Action::"ExternalDocsTool___invoke"
&&
principal.getTag("groups").contains("docs-team")
)
)
};
Note: AgentCore Gateway generates action names in the format TargetName___action_name for each registered target (for example, DeployCI___invoke, RiskModel___invoke_risk_model). The action part varies per tool. Verify these names against the published schema for your Gateway using the tools/list MCP capability.

Per-repository tool governance

For organizations with multiple teams, Cedar policies scope tool access per repository. Create IdP groups reflecting repository ownership (for example, repo-payments-service, repo-web-app). AgentCore Identity maps these to Cedar principal tags via the OIDC claim mapping from Step 1. Then write permit policies restricting each group to its approved tools.
The following example shows three teams with distinct tooling needs, all enforced through a single Gateway:
cedar
// Policy 1: payments-service repository
// Members of repo-payments-service group can invoke payment
// processing and database tools, but ONLY in staging environment.
// This prevents accidental production changes by the payments team.
permit (
principal,
action,
resource
)
when {
// Scope to this Gateway instance
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/company-gateway"
&&
// Check group membership from IdP claims (mapped in Step 1).
// Uses .contains() because IdP sends groups as an array.
principal.hasTag("groups") &&
principal.getTag("groups").contains("repo-payments-service")
&&
// Allow only these three tools for this team
action in [
AgentCore::Action::"PaymentAPI___invoke",
AgentCore::Action::"DatabaseQuery___invoke",
AgentCore::Action::"DeployCI___invoke"
]
&&
// Restrict all three tools to staging environment only
context.input.environment == "staging"
};
// Policy 2: web-app repository
// Frontend team can use design and documentation tools.
// No environment restriction — these tools are safe for any context.
permit (
principal,
action,
resource
)
when {
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/company-gateway"
&&
principal.hasTag("groups") &&
principal.getTag("groups").contains("repo-web-app")
&&
action in [
AgentCore::Action::"DesignSystem___invoke",
AgentCore::Action::"DocsSearch___invoke",
AgentCore::Action::"ComponentLib___invoke"
]
};
// Policy 3: infra-core repository
// Platform team has broader access including deployment and ops tools.
// Note: DeployCI appears here AND in Policy 1 — shared tools can have
// different conditions per team (staging-only for payments, unrestricted
// for platform).
permit (
principal,
action,
resource
)
when {
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/company-gateway"
&&
principal.hasTag("groups") &&
principal.getTag("groups").contains("repo-infra-core")
&&
action in [
AgentCore::Action::"DeployCI___invoke",
AgentCore::Action::"CloudOps___invoke",
AgentCore::Action::"MonitoringDashboard___invoke"
]
};
Shared tools (such as DeployCI) can have different conditions per team. Adding a new repository team requires only a new IdP group and Cedar policy. For organizations with many repositories, manage policies through a Git-based workflow with security-team approval.
After completing this step, Cedar policies enforce tool-level authorization based on principal identity and input parameters at the Gateway boundary.

Step 4 — Configure Kiro Enterprise MCP Registry

Configure a  central MCP registry endpoint  at the Kiro administrative level rather than distributing local configuration files to each developer.
The platform team defines a registry endpoint (for example,  https://mcp-registry.company.internal ). Kiro IDE retrieves approved MCP server metadata exclusively from this endpoint. The registry lists only the organization’s AgentCore Gateway as the approved MCP server. All tool invocation traffic flows through the Gateway.
For organizations that need discovery beyond Kiro — for example, other AI agents, custom client applications, or non-IDE users browsing a catalog —  AWS Agent Registry  provides a fully managed, AWS-native catalog for MCP servers, tools, agents, and skills, with a publisher/curator approval workflow and hybrid semantic-plus-keyword search. Agent Registry complements the Kiro Enterprise MCP Registry rather than replacing it: Kiro handles IDE-side discovery for developers, while Agent Registry serves organization-wide consumers. Both can point to the same AgentCore Gateway endpoint, preserving the single-endpoint governance model described in the architecture.
After completing this step, Kiro IDE retrieves the approved MCP server list from the central registry, directing all tool traffic through the Gateway.

Step 5 — Audit, monitoring, and incident response

  • CloudWatch / AgentCore Observability: AgentCore is designed to log each decision and tool invocation. Forward logs to your security information and event management (SIEM) system (CloudWatch Logs → Lambda → Splunk or Elasticsearch).
  • Policy change audit: Use a Git-based workflow (GitOps) for policy sources (store natural-language policy requests + generated Cedar in a repo) and require pull request approval from security/compliance before applying.
  • Runtime alerts: Create CloudWatch metrics for denied tool calls, sudden spikes in tool usage, or calls with unusual input parameters.
After completing this step, policy decisions, tool invocations, and access denials are logged and monitored centrally.

Verify your implementation

After completing Steps 1–5, verify the end-to-end flow:
  1. Confirm the Gateway is active: run aws bedrock-agentcore-control describe-gateway --gateway-identifier company-gateway and verify the status is ACTIVE.
  1. Confirm targets are registered: run aws bedrock-agentcore-control list-gateway-targets --gateway-identifier company-gateway and verify your targets appear.
  1. Test authorization: invoke a tool through Kiro with an authorized account and confirm the request succeeds. Then test with an unauthorized account and confirm the request is denied.
  1. Check audit logs: open the CloudWatch Logs log group for your Gateway and verify that policy decisions (Allow/Deny) appear with the correct principal identity.

Troubleshooting

  1. Authentication failures: verify the OIDC discovery URL is reachable from the Gateway, confirm the token audience matches the allowedAudience configuration in the Gateway, and check that the IdP token has not expired.
  1. Policy denials: confirm that the Cedar policy principal tags match the IdP group claims. Start with LOG_ONLY enforcement mode to inspect policy decisions without blocking requests.
  1. Tool not discoverable: confirm the target is registered (list-gateway-targets) and that the Gateway status is ACTIVE (describe-gateway).

Example “publish flow” for new MCP tools

  1. Developer or team proposes a new tool via pull request (PR), including: tool name, owner, allowed principals/groups, intended inputs, and risk assessment.
  1. Platform team reviews the proposal and runs security and integration tests.
  1. Platform team registers the target with AgentCore Gateway and creates a Cedar policy controlling who can invoke it.
  1. Platform team updates the central mcp-registry.json and CI publishes the updated manifest.
  1. Monitor usage for 7–14 days before relaxing restrictions.

Security considerations

  • Do not rely on client-side enforcement only. Developers can edit their local mcp.json unless you control network egress and/or manage the client config centrally. Network controls are the hard stop.
  • Apply the principle of least privilege: start with coarse-grained policies (allow/deny tool) and progressively refine to parameter-level checks. Use LOG_ONLY mode during rollout, then switch to ENFORCE. AgentCore supports natural-language-to-Cedar policy generation.
  • Secrets handling: do not store secrets in environment variables or plain text configuration files. Use the Gateway and AgentCore Identity to mediate requests and inject ephemeral credentials.
  • Performance: Gateway and Policy are in-line; measure latency and scale the Gateway accordingly.
  • Input validation: validate tool input parameters against expected types and formats. For database tools, use parameterized queries. For tools accepting free-text input, implement allow list-based validation to help protect against injection attacks.
  • Token storage: store authentication tokens (such as GATEWAY_AUTH_TOKEN) in a secure credential manager ( AWS Secrets Manager , operating system keychain, or a secrets vault) rather than in plain text configuration files. Use short-lived tokens with automatic refresh in production.
  • Encryption: require TLS 1.2 or later for all Gateway connections. Enable encryption at rest for Aurora databases and S3 buckets using AWS KMS. Enable encryption for CloudWatch Logs log groups storing audit trails.

Protecting resources with IAM guardrails

AgentCore Gateway policies are the first line of defense. IAM policies add a second layer using two MCP-aware condition keys: aws:CalledViaAWSMCP (a string key targeting a specific MCP service) and aws:ViaAWSMCPService (a boolean key matching any MCP-initiated request). The following IAM deny policy prevents accidental  Amazon Simple Storage Service (Amazon S3)  bucket deletion from MCP tool invocations. The same pattern applies to  DynamoDB, RDS , or any other service — as a Service Control Policy (SCP) attached to a production organizational unit (OU), it helps protect resources across the target accounts.
Policy example:
JSON
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyS3DeleteViaAnyMCP",
"Effect": "Deny",
"Action": [
"s3:DeleteBucket",
"s3:DeleteObject",
"s3:DeleteObjectVersion"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition": {
"Bool": {
"aws:ViaAWSMCPService": "true"
}
}
},
{
"Sid": "DenyS3DeleteViaSpecificMCP",
"Effect": "Deny",
"Action": [
"s3:DeleteBucket",
"s3:DeleteObject",
"s3:DeleteObjectVersion"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition": {
"StringEquals": {
"aws:CalledViaAWSMCP": "aws-mcp.amazonaws.com"
}
}
}
]
}
The first statement (DenyS3DeleteViaAnyMCP) uses the boolean condition key aws:ViaAWSMCPService to blanket-deny S3 deletions from any MCP service. The second statement (DenyS3DeleteViaSpecificMCP) uses the string condition key aws:CalledViaAWSMCP to target a specific MCP service by its principal name. Direct console or CLI operations by administrators remain unaffected. The same pattern applies to Amazon DynamoDB, Amazon RDS,  AWS Key Management Service (AWS KMS) , or any other AWS service — substitute the relevant actions and resources.

What success looks like (metrics)

  • Ideally, all developer MCP traffic flows through the company Gateway, verified via network logs and Amazon VPC flow logs.
  • All new tool additions require an approved gateway policy and a recorded owner, tracked through your change-management process.
  • Denied calls (policy blocks) trending to zero after 90 days, indicating stabilized rules.

Cost estimation example

Consider a team of 50 developers using 10 MCP servers (approximately 50 tools) through AgentCore Gateway over one month:
  • At approximately 572,000 monthly MCP operations (500 invocations/developer/day × 22 days + discovery calls):
  • AgentCore Gateway: ~$2.87/month ($5 per million operations + $0.02 per 100 tools indexed).
  • AgentCore Identity: no additional charge when used through Gateway.
  • AgentCore Policy: consumption-based pricing per authorization request.
Total estimated monthly governance cost: approximately $2.87 for the Gateway, Identity, and Policy layer — for the entire team of 50 developers.

Extending governance with Open Policy Agent (OPA)

Cedar provides comprehensive static authorization at the Gateway boundary. For dynamic policy evaluation — payload content inspection, time-based access windows, rate limiting, or sensitive data detection in tool arguments — Open Policy Agent (OPA) can serve as a complementary layer.

When to consider adding OPA

  • Payload content inspection or time-based/rate-based access controls that Cedar cannot express.
  • Cross-stack policy reuse (Kubernetes, Terraform, API authorization) or hot-reload policies without Gateway redeployment.
If your requirements are limited to role-based tool access and parameter-level conditions, Cedar alone is sufficient.
OPA can be deployed as a request interceptor implemented with Lambda between the Gateway and backend targets: Developer → AgentCore Gateway (Cedar) → Interceptor Lambda (OPA) → MCP Target.
Example: Rego (the OPA policy language) policy for MCP tool governance
rego
package mcp.tools
import rego.v1
default allow := false
# Read-only tools: allow for any authenticated user
allow if {
startswith(input.tool, "read_")
input.claims.sub != ""
}
# Write tools: admin role only, during business hours (UTC)
allow if {
input.tool == "db_write"
input.claims.role == "admin"
clock := time.clock(time.now_ns())
clock[0] \>= 9
clock[0] \< 17
}
# For payload content inspection (such as SQL injection detection),
# use a dedicated input validation library or a web application firewall (AWS WAF).
# See OWASP Input Validation Cheat Sheet for recommended approaches.
This policy demonstrates capabilities Cedar cannot express natively: time-of-day restrictions and pattern-based tool matching. For payload content inspection (such as SQL injection detection), use a dedicated input validation library or a web application firewall (WAF).

Clean up

To avoid ongoing charges, delete the resources you created in reverse dependency order:
  • List gateway targets: aws bedrock-agentcore-control list-gateway-targets --gateway-identifier company-gateway
  • Delete each gateway target: aws bedrock-agentcore-control delete-gateway-target --gateway-identifier company-gateway --target-id <target-id>
  • List Cedar policies: aws bedrock-agentcore-control list-policies --policy-engine-id <engine-id>
  • Delete each policy: aws bedrock-agentcore-control delete-policy --policy-engine-id <engine-id> --policy-id <policy-id>
  • Delete the policy engine: aws bedrock-agentcore-control delete-policy-engine --policy-engine-id PlatformPolicyEngine-abc123
  • Delete the AgentCore Gateway: aws bedrock-agentcore-control delete-gateway --gateway-identifier company-gateway
  • Detach any policies attached to IAM roles created for the Gateway (for example, GatewayRole).
  • Delete the IAM role: aws iam delete-role --role-name GatewayRole
  • Delete Lambda functions created for MCP tool wrappers: aws lambda delete-function --function-name <function-name>. Delete CloudWatch Log groups and S3 buckets created for MCP tool implementations and registry hosting.
Warning: Deleting CloudWatch Log groups permanently removes audit trails. Export logs to S3 for long-term retention before deletion if required for compliance.
Verify cleanup: run aws bedrock-agentcore-control describe-gateway --gateway-identifier company-gateway and confirm the command returns ResourceNotFoundException.

Conclusion & next steps

This pattern — Kiro Enterprise MCP Registry + AgentCore Gateway with OIDC authentication and Cedar policy enforcement — lets developers use MCP tooling while keeping governance under central control.
For a quick pilot:
  1. Deploy a Gateway in a sandbox account
  1. Register one internal target
  1. Create a Cedar policy scoped to your team
  1. Configure Kiro to point to the Gateway
  1. Apply network rules to restrict MCP traffic, and monitor logs.
  1. Iterate on policies based on observed patterns.

References / further reading

  • AWS Well-Architected Framework  Security Pillar  — best practices for securing workloads on AWS.
  •  AWS Agent Registry  — fully managed catalog for MCP servers, tools, agents, and skills, with approval workflows and semantic search.
  • 



About the Author

Alex Kronfeld is a Senior Solutions Architect at AWS, based in Israel. He is passionate about resilience, disaster recovery, and generative AI — and helping organizations adopt governance patterns that keep innovation secure at scale.

Acknowledgments

Special thanks to Nati Goldberg, Mark Keating, Liran Sehayk, and Dor Fibert for their reviews and feedback during the preparation of this post.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article