Governing MCP in the Enterprise: A Decision Framework and a Paved Road on AWS

Agents are arriving through every door. Knowledge workers get Copilot and Claude, product teams adopt agent frameworks, and ERP and ITSM vendors ship their own MCP servers. Every one of them wants tools: read an order, fetch a quality certificate, draft a non-conformance report, approve a release.

Analysis — recommendation: Do not govern MCP server by server. Give every request the same five questions, a federated operating model that keeps business authority with the domains, one AWS reference architecture, and a paved road that makes the governed path the fastest one.

This article turns the AgentCore Gateway series and the Governed Agent Tooling on AWS whitepaper into an organisation-level proposal. The running example is a multi-entity industrial manufacturer: shared SAP, plants in several countries, segregated OT networks, and some export-controlled engineering data.

Table of contents

Why MCP needs an enterprise stance

Without a deliberate stance, the failure modes repeat across teams:

Verified AWS behavior: AgentCore Gateway rate limits fail open on transient errors, and Policy evaluation applies to MCP tools only — prompts and resources are always allowed. Sources: AgentCore release notes; Use Gateway with Policy.

Seven principles

1. Gateway enforces; the business system decides. Cedar decides which tool, with which arguments, for which principal. Only the system of record knows whether order 4711 belongs to the French entity.
2. Identity and entity come from the token, never from the model.
3. Curate operations, not capabilities. One tool, one business effect, one owner, one test matrix.
4. Governance effort follows harm. Four risk tiers with cumulative controls.
5. Consequential actions are proposals. They create an approval bound to the exact intent.
6. Default deny, evidence always.
7. Paved road over policing. The secure path must be the fastest path.

The decision framework: five questions

Figure 1 — The decision framework. Knock-out questions first, scored choices second. Editable draw.io.

Q1 — Should this be MCP at all?

Choose MCP when two or more agent consumers need the same tools, tools must be discoverable, users delegate access to many tools through one endpoint, or the server joins a shared platform. Otherwise a normal API with a framework tool adapter is simpler, and it does not add prompts, resources and sessions to govern.

Q2 — Which control plane?

Knock-outs come first:

Then a weighted comparison, owned by the design authority:

Analysis: on AWS, the managed gateway usually wins because it supplies what we would otherwise build and operate: inbound and outbound authentication, default-deny Cedar with discovery filtering, a per-user token vault, sessions, semantic search and rate limits. Portability is the honest weakness, and it is a reconsideration trigger in every ADR.

Q3 — Which controls does each tool need?

Classify by worst credible effect, including bulk extraction:

Q4 — How strongly must partitions be isolated?

Pooled is the default: one domain gateway, with the legal entity or plant carried as a JWT claim, a Cedar condition, and row-level scope in the backend. Partitioned means a separate gateway and policy engine for contractual or export-controlled data. Siloed means a dedicated account per entity when a joint venture, regulator or customer contract requires it.

Q5 — Build, wrap or reuse?

Wrap existing ERP APIs as Lambda or OpenAPI targets with curated verbs; this is the default for SAP. Reuse vendor MCP servers only behind the gateway, with an allow-list and drift detection. Build a custom server on AgentCore Runtime only for stateful sessions or long-running jobs.

The output is one ADR per MCP server: control plane and Region, tiers and controls per tool, partition model, server strategy, named owners, open gates, cost envelope and reconsideration triggers.

A federated operating model

Figure 2 — Central paved road, domain ownership. Editable draw.io.

• MCP Design Authority — enterprise architecture (chair), CISO office, data governance, legal and export control. It owns standards, the tier model, the framework weights and time-boxed exceptions.
• MCP Platform team — runs gateways, policy engines, identity providers, the registry, observability, cost allocation, break-glass and DR drills. It also maintains the plugin.
• Domain teams — own tool purpose, schemas, adapters, backend isolation, runbooks and on-call.
• Business risk owners — sign T2/T3 tools and their limits, and hold approval authority without infrastructure rights.

Analysis: separation of duties must be enforced in IAM, not in a slide. A tool author cannot change production policy or the engine mode. The release identity is automation. Platform administrators hold no business approval rights.

The AWS reference architecture

Figure 3 — Target state. Numbers follow one tool call. Editable draw.io.

Key choices:

• One gateway per domain. This keeps blast radius and execution roles separate, stays under the 100-target ceiling, and gives each domain its own policy engine.
• CUSTOM_JWT inbound for user-delegated calls. Verified AWS behavior: IAM inbound is rejected when any target uses three-legged OAuth.
• Private reach. Lambda adapters reach SAP; OpenAPI and MCP-server targets reach private services through VPC Lattice. Private API Gateway and Smithy targets cannot reach private systems directly.
• Policy rollout. The engine runs in LOG_ONLY in dev and stage. In production the engine is always ENFORCE, and a changed policy is shadowed with its own enforcementMode: LOG_ONLY until reviewed. Source: AWS::BedrockAgentCore::Policy.
• Region. Verify before deployment: Policy coverage differs by Region. For EU workloads, confirm Frankfurt or another Policy Region on the official page. Paris has been reported Gateway-only by a third-party audit.

One tool call, five checkpoints

Figure 4 — Where each guarantee is actually enforced. Editable draw.io.

1. IdP — issues an access token with scopes and entity/plant claims.
2. Gateway authorizer — validates issuer, audience, client and expiry; ingress is private.
3. Cedar — filters tools/list and evaluates tools/call with the real arguments; default deny, forbid wins.
4. REQUEST interceptor — strips identity-like arguments and injects a trusted context built from validated claims. Verified AWS behavior: request interceptors receive the MCP request (and headers when passRequestHeaders is true) and return a transformed request or an immediate response. Source: Types of interceptors.
5. System of record — scopes every query by the trusted partition, enforces idempotency and records the business outcome.

A Cedar rule for a sensitive read looks like this. The action name is <TargetName>___<tool>, and claims are principal tags:

permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"QualityCertificatesTools___get_inspection_certificate",
  resource == AgentCore::Gateway::"${GatewayArn}"
)
when {
  principal.hasTag("scp") &&
  principal.getTag("scp") like "*quality/read*" &&
  principal.hasTag("legal_entity")
};

It proves the caller may read certificates. It does not prove the certificate belongs to the caller’s entity. That check lives in checkpoint 5.

The paved road: a plugin from requirements to deployment

Figure 5 — Seven stages, seven gates, one source of truth. Editable draw.io.

Standards documents do not change behaviour; defaults do. I packaged the framework as mcp-architect, a Claude Code plugin with seven skills, a /design-mcp command and an independent reviewer agent. A single mcp-spec.yaml is the source of truth, and scripts enforce the rules instead of describing them:

The CDK template wires CfnGateway, CfnGatewayTarget, CfnPolicyEngine and CfnPolicy with an interceptor and an idempotent adapter. Verified: it type-checks and synthesises against aws-cdk-lib 2.274.0. Verify before deployment: the IAM actions the gateway role needs for policy evaluation, and whether injected context must be declared in the tool schema for your target type.

The target I use for the paved road: a sensitive read tool from requirements to production in four weeks or less, with evidence attached to the ADR rather than assembled afterwards.

Cost and quotas

Verified AWS behavior (pricing page, 21 October 2026): $5 per million invocations, $25 per million search calls, $25 per million policy authorizations, $0.02 per 100 tools per month, $0.006 per GB to customer VPCs, and Identity free through the gateway.

For 200 users with 12 interactions a day, one search and four tool calls each, the gateway layer costs about $8 per month. At ten times that volume it is about $84. Policy authorization is the largest gateway meter, and that is the price of central authorization rather than something to optimise away. The real costs are engineering time for curated tools, compute, observability, connectivity and inference — so manage cost per completed business task.

Default quotas shape the design more than price does: 200 TPS for tool calls, shared at gateway and account level; 25 search calls per minute; 100 targets per gateway; 6 MB payloads; a 15-minute invocation timeout.

Roadmap: authority expands only after evidence

Figure 6 — Phased rollout with gates and containment. Editable draw.io.

Containment works the same in every phase: a targeted Cedar forbid, then a backend kill switch, then reconciliation of in-flight writes. Rate limits are never the safety net.

What this means in practice

• Decide once, apply everywhere. Five questions and an ADR per server beat a bespoke security review per integration.
• Keep the split explicit. Gateway solves reachability and enforcement. Business authorization, partition isolation, approvals and correctness stay with the domain, and acceptance tests prove both halves.
• Ship defaults, not documents. A validator that rejects run_sql, a scaffolder that generates default-deny policies, and a pipeline that keeps production in ENFORCE do more than any standard.
• Expand authority only with evidence. Reads first, reversible writes next, consequential actions last — each behind a gate you can show an auditor.

Next action: take one real tool request in your organisation, write its mcp-spec.yaml, and run it through the five questions before anyone writes code.