This section outlines the security guarantees provided by the OpenEdge MCP Server and the recommended best practices for maintaining robust security posture. It explains the default protections built into the architecture and offers guidance on encryption, authentication, token management, and operational hardening to minimize risk and ensure compliance.

Security guarantees

These guarantees form the foundation of the MCP Server security model, minimizing risk and enforcing least privilege:
  • Service account credentials are never sent to PAS for OpenEdge services.
  • Non-GET operations remain blocked unless explicitly enabled, enforcing least privilege.
  • Token exchange produces short-lived, scope-limited tokens.
  • Response and rate limit guards protect performance and cost.

Recommended security posture and best practices

To maintain a strong security posture and reduce the risk of unauthorized access or lateral movement, follow these best practices:
Best practice Details
Encrypt all connections
  • Use TLS for every communication hop:
    • Client → MCP Client (if remote)
    • MCP Client → MCP Server
    • MCP Server → PAS for OpenEdge SSO
    • MCP Server → PAS for OpenEdge Services
  • Enable mutual TLS (mTLS) wherever both endpoints are under your control:
    • At minimum: MCP Client → MCP Server
    • Optionally, PAS for OpenEdge SSO and PAS for OpenEdge Services if they support client certificate validation
This best practice ensures confidentiality, integrity, and authenticated channels, reducing the risk of header or token interception.
Prefer token exchange over direct token pass-through
  • Allow the MCP Server to issue backend tokens so downstream services trust it as the controlled issuer.
  • Use short-lived, scope-limited tokens to minimize exposure compared to long-lived generic user tokens.
  • If token exchange fails, deny the request rather than falling back to the original user token.
Enforce dual authentication and scope-gating
  • Keep service account verification enabled to establish a stable server identity separate from the end-user.
  • Apply scope filtering and default read-only routing to ensure only authorized tools are visible and executable.
Rotate cryptographic material regularly
  • Rotate the following at the recommended cadence of 30-90 days, based on sensitivity:
    • Service account keys
    • Token signing keys (if applicable)
    • TLS/mTLS certificates
Harden TLS configuration
  • Use modern cipher suites and disable legacy protocols, such as TLS 1.0/1.1.
  • Validate server hostname and CA chain for PAS for OpenEdge SSO and PAS for OpenEdge Services.
  • Pin CA roots if allowed by organizational policy.
Minimize token scope and lifetime
  • Issue tokens with only the required scopes and claims.
  • Set short TTL: minutes to a few hours.
  • Reject or re-exchange tokens older than your policy threshold.
Monitor and alert
  • Track:
    • Rate limit denials
    • Authentication failures
    • Token exchange errors
  • Treat unusual spikes as potential abuse.
  • Log structured events (excluding secrets) to central Security Information and Event Management (SIEM) for anomaly detection.
Fallback policy
  • If token exchange is unavailable, deny the request explicitly.
  • Do not silently forward raw user tokens, as this weakens security.