Enterprise MCP Governance Gateway

What it is

• Single governed MCP endpoint in front of MCP tool servers
• Cognito OIDC JWT authentication (CUSTOM_JWT authorizer)
• Cedar policy engine in ENFORCE mode, one policy per statement
• Request and response Lambda interceptors (SQL-injection blocking, business-hours gating, payload truncation)
• Managed Bedrock Guardrail with regex PII redaction as defense in depth, plus structured audit logging
• Optional per-user OAuth 3LO connectors (Atlassian)
• Five governance tests that run against the live gateway, never mocked

Source: README.md (opens in new tab)

Status

Version

not documented No version badge, tag or CHANGELOG in the project folder.

Status

Sample and demonstration stack; not hardened for production README.md: Security notes (opens in new tab)

Recent changes: commit history for enterprise-mcp-governance-gateway on GitHub (opens in new tab)

No open advisories are tracked for this project.

At a glance

Compare all four projects

Quickstart

See it work

The README walkthrough drives the governed tools from a real coding agent. The outcome is produced by the gateway, not the agent. Cedar both hides a forbidden tool and denies it, and hiding wins. An agent therefore never triggers the deny in case C; the README shows a direct curl call that does. README.md (opens in new tab)

export_pii_report and query_audit_logs are gated to 09:00 to 17:00 UTC by the request interceptor. Outside that window they are blocked before execution. README.md (opens in new tab)

Source: README.md (opens in new tab)

Compared with the workshop

Cedar policy

forbid-destructive-db.cedar carries no role or identity gate, so every statement in it applies to the seeded users. The CDK deploys one policy per statement. The notes below follow the statements in file order.

// Policy 3: Forbid destructive database operations for everyone, and constrain
// execute_query to read-only SELECT statements.
// Resource ARN is substituted at deploy time (token __GATEWAY_ARN__).

// Block ALL users from calling destructive database tools regardless of role.
// One single-action forbid per tool: the policy engine does not match Cedar
// action set-membership (`action in [...]`) for tool authorization.
forbid(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"DatabaseAPI___drop_table",
  resource == AgentCore::Gateway::"__GATEWAY_ARN__"
);

forbid(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"DatabaseAPI___truncate_table",
  resource == AgentCore::Gateway::"__GATEWAY_ARN__"
);

forbid(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"DatabaseAPI___delete_records",
  resource == AgentCore::Gateway::"__GATEWAY_ARN__"
);

// Allow read-only database queries for all authenticated users.
permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"DatabaseAPI___execute_query",
  resource == AgentCore::Gateway::"__GATEWAY_ARN__"
)
when {
  context.input has query &&
  context.input.query like "SELECT *"
};

// Forbid execute_query if it contains dangerous patterns.
forbid(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"DatabaseAPI___execute_query",
  resource == AgentCore::Gateway::"__GATEWAY_ARN__"
)
when {
  context.input has query &&
  (context.input.query like "*DROP*" ||
   context.input.query like "*DELETE*" ||
   context.input.query like "*TRUNCATE*" ||
   context.input.query like "*INSERT*" ||
   context.input.query like "*UPDATE*")
};

1. forbid DatabaseAPI___drop_table. Forbids drop_table for every authenticated user, whatever their role.

   Source: forbid-destructive-db.cedar (opens in new tab)

2. forbid DatabaseAPI___truncate_table. Forbids truncate_table for everyone. Each tool gets its own single-action statement because the policy engine does not match Cedar action set-membership.

   Source: forbid-destructive-db.cedar (opens in new tab)

3. forbid DatabaseAPI___delete_records. Forbids delete_records for everyone.

   Source: forbid-destructive-db.cedar (opens in new tab)

4. permit DatabaseAPI___execute_query. Permits execute_query only when the query argument matches like "SELECT *". In Cedar the asterisk is a wildcard, so this is a case-sensitive prefix match on SELECT followed by a space, not a literal SELECT * statement. A lower-case select does not match and falls to the default deny.

   Source: forbid-destructive-db.cedar (opens in new tab)

5. forbid DatabaseAPI___execute_query. Forbids execute_query when the query contains DROP, DELETE, TRUNCATE, INSERT or UPDATE in upper case. Cedar like is case-sensitive; the case-insensitive catch is the request interceptor regex, compiled with re.IGNORECASE, which runs before Cedar.

   Source: forbid-destructive-db.cedar (opens in new tab), index.py (opens in new tab)

All 7 policy files, each with a purpose line

Claims that reach Cedar

The gateway validates the Cognito access token, and its claims become Cedar principal tags. The ID token is rejected, so claims that live only there never reach a policy.

Before you demo

Architecture and figures

The gateway README has no architecture image. The request path in the page header is drawn from its Verified architecture section. README.md: Verified architecture (opens in new tab) Read it in the rendered README.

Architecture across all four projects

Known limitations and support envelope

Each item is copied from the project README or docs without paraphrase.

• Not hardened for production. This is a sample / demonstration stack. It is deployed to a real account and is safe to demo, but it is not hardened for production README.md: Security notes (opens in new tab)
• Access token versus ID token. Query F is a known demo limitation, not a bug. custom:role therefore never reaches the policy engine, so the role-gated permit never fires. README.md (opens in new tab)
• Tighten the gateway-resource IAM scope for multi-gateway accounts. This sample deploys a single gateway, so the wildcard effectively resolves to it. If your account runs multiple gateways in the region, restrict the statement to the specific gateway ARN after the first deploy, or use a two-phase deploy (create the gateway, then update the policy with its exact ARN). README.md: Tracked production hardening (not in this sample) (opens in new tab)
• Env-based config profiles. ENFORCE + no exceptionLevel for prod (DEBUG returns verbose denial reasons, useful only for a demo). README.md: Tracked production hardening (not in this sample) (opens in new tab)
• Cognito pre-token-generation Lambda. A Cognito pre-token-generation Lambda to surface custom:role in the access token, so the role-based Cedar policies fire (today role/email live only in the ID token, which the gateway does not validate). README.md: Tracked production hardening (not in this sample) (opens in new tab)
• Per-Lambda log retention. Per-Lambda log retention. README.md: Tracked production hardening (not in this sample) (opens in new tab)

Support envelope for all projects

Evidence

The README ships five integration tests that run against the deployed gateway, a one-command smoke test, and local unit tests for the interceptors.

source scripts/get-token.sh
GATEWAY_URL="$(aws ssm get-parameter --region "$AWS_REGION" \
  --name /enterprise-mcp-gateway/gateway/url --query Parameter.Value --output text)" \
AUTH_TOKEN="$AGENTCORE_JWT" \
  python3 -m pytest tests/integration -v

source scripts/get-token.sh
bash scripts/test-gateway.sh

python3 -m pytest tests/unit -v

Documentation on this site

• README: Enterprise MCP Governance Gateway (AWS AgentCore)
• Atlassian connector: Atlassian connector (Jira & Confluence): per-user 3LO

Teardown

cd cdk
cdk destroy EnterpriseMcpGatewayStack
cd ..

Costs and cleanup for all projects