Before promoting an MCP deployment to production, it is critical to validate that all components, such as OpenAPI specifications, authentication, authorization, routing, and hardening controls, meet security and compliance standards. This checklist serves as a quality gate to ensure there are no gaps across individual configurations and that the deployment is robust, secure, and maintainable.

OpenAPI specification quality

The OpenAPI specification must be clean and expose only intended operations. Ensure the OpenAPI specification meets these conditions:
Requirement Description
Unique operation ID per opertation Each operation must have a unique and stable operationId.
Complete descriptions Include descriptions, component schemas, pagination details, and error schemas.
Lint clean Validate that the specification passes lint checks.
Expose only intended operations Confirm that only the required endpoints are exposed.

Authentication and scopes

Use the following checklist to verify authentication and scope requirements:
Requirement Description
Service account configuration Set up service_account.* for production. Optionally, you can configure user token exchange (user_auth.*).
Scope definition Define scopes in security.authorization.tools.

Downstream hardening

Apply security and performance controls:
Requirement Description
Limit surfaced routes Use INCLUDE maps. Default to read-only routes.
Audit and scope writes Ensure write operations are audited and scoped.
Paginate large responses Bound large responses to prevent overload.

TLS and mTLS configuration

Secure transport for inbound and outbound traffic:
Requirement Description
Inbound TLS Configure runtime.server.transport.tls.* and enable require_client_cert for mTLS if needed.
Outbound TLS Trust CA using runtime.http.tls.ca_bundle; provide client certificate if required.

JWKS and key rotation

Implement secure key management:
Requirement Description
JWKS URI Use jwks_uri with short cache duration.
Algorithm restrictions Restrict algorithms if desired.

Integrated gate purpose

This gate verifies that all security, routing, and hardening controls work together before enabling user access. It ensures there are no gaps between individual checklists, and verifies:

  • Authentication—Valid tokens are accepted, and invalid or expired tokens are rejected with HTTP status codes 401 or 403.
  • Authorization and scopes—Tools without granted scopes disappear from discovery, and scoped write tools return HTTP 403 when the required scope is missing.
  • Transport security—All endpoints are reachable only over TLS, and the mTLS handshake succeeds or fails as configured.
  • Response guardrails—Size and item count limits trigger graceful truncation or policy errors instead of causing server failures.
  • Route mapping—Only intended PAS for OpenEdge endpoints are exposed, and any removed paths return HTTP 404.
  • Export integrity—The deployment is built using the --bundle prod option, and container references confirm clean production artifacts.
  • Logging and privacy—Logs do not contain sensitive fields or raw tokens, and debug logging is disabled in production.
  • Observability hooks—Authentication failures, guard rejections, and rate limits generate structured log entries or metrics for alerting.

Actionable gate checklist

Use this checklist to validate that all integrated security, routing, and hardening controls function correctly before promoting the deployment to production:
  • Negative authentication tests return only 401/403 (never 200 or 500).
  • Scope removal hides tools from discovery and returns 403 if invoked manually.
  • Oversized response triggers response guard with sanitized error and log entry.
  • Disallowed routes return 404.
  • All endpoints are accessible only through HTTPS. HTTP requests fail.
  • mTLS blocks clients without valid certificates and allows those with valid certs.
  • Logs are free of secrets and tokens; request IDs traceable end-to-end.
Gate outcome: Promote only when every check passes. Failures must be remediated in the relevant section, such as authentication, TLS, hardening, JWKS.

Rotation matrix

Use this rotation matrix to plan and enforce regular key, certificate, and configuration updates across all critical areas to maintain security and compliance:
Area Keys Artificate/scope Rotation cadence/trigger
OpenAPI specification api.openapi.* OpenAPI YAML Whenever there is a schema change that requires a version bump
Authentication and authorization security.authentication.*, security.authorization.* Service account keys, JWKS, token exchange endpoint Service account keys every 30–90 days, and ensure user tokens remain short-lived
Routes and HTTP configuration api.routes.*, runtime.http.* PAS for OpenEdge upstream endpoints Whenever there is a new release or when upstream endpoints change
Transport Layer Security (TLS) runtime.server.transport.tls.*, runtime.http.tls.* TLS certificates and CA bundle Every 60–90 days or before certificate expiry
JSON Web Key Set (JWKS) jwks_uri Remote JWKS JSON Based on IdP policy, and refresh based on the cache TTL setting.