Security Overview
Smplify MCP requires OAuth 2.1 for Claude, ChatGPT, and other remote clients connecting to the hosted service. This page summarizes the live controls behind that production authorization boundary.
https://auth.smplify.com with Smplify-issued, audience-bound MCP tokens. MCP client configurations never contain or receive an upstream Smplify API credential; browser authorization relays that credential into a private connector vault with AWS KMS-backed envelope encryption and an explicit lifecycle from ACTIVE to EXPIRING_SOON to RECONNECT_REQUIRED.
This page stays focused on live controls. The customer guidance page covers trusted client usage, prompt-injection hygiene, token handling, and human approval recommendations.
Hosted Architecture Flow
1. OAuth discovery on the MCP domain
Remote clients start from https://mcp.smplify.com/mcp and discover protected-resource and authorization-server metadata on the MCP domain. Client ID Metadata Documents are supported for current public clients, with Dynamic Client Registration retained as a compatibility fallback.
2. Smplify-owned connector auth
auth.smplify.com handles the OAuth 2.1 authorization flow and returns a Smplify-issued MCP token rather than exposing the upstream Smplify API bearer token to the client.
3. Private connector vault
If the upstream Smplify API still requires a bearer-token bridge, the token is stored only in the separate connector vault service over the internal Railway path, not on the public MCP surface.
4. KMS-backed storage
The connector vault now uses AWS KMS-backed envelope encryption in production. Legacy env-key fallback is disabled, and existing connection records were migrated to aws-kms.
5. Upstream session lifecycle manager
The vault-owned lifecycle manager tracks ACTIVE, EXPIRING_SOON, RECONNECT_REQUIRED, and REVOKED, and connector refreshes consult that state before minting fresh MCP tokens.
6. Tenant-aware MCP execution
The MCP gateway validates issuer and audience, resolves the connection from the private vault, and enforces explicit tenant context for multi-tenant writes before making upstream platform calls.
What We Enforce
Transport and browser protections
Public traffic is redirected to HTTPS, HSTS is enabled, clickjacking is blocked, Host and Origin headers are validated to reduce DNS rebinding exposure, and the portal uses a strict content security policy with only the browser connections it needs.
Authentication boundaries
The setup page emits headerless configurations for the canonical protected resource. OAuth sign-ins run through auth.smplify.com, where Smplify issues audience-bound MCP tokens and keeps any temporary upstream credential bridge encrypted, revocable, server-side only, and KMS-backed.
Upstream session lifecycle
OAuth-backed connector sessions are tracked through explicit lifecycle states. Active upstream Smplify sessions stay usable, connections nearing expiry are marked EXPIRING_SOON so the gateway can recommend reconnect early, expired sessions move to RECONNECT_REQUIRED, and revoked bridges stay blocked until a new sign-in completes.
Operational throttling
Each bearer token or connector session is rate limited before tool execution, and repeated failed authentication attempts are temporarily throttled to reduce brute-force noise against the hosted gateway and OAuth surfaces.
Auditability
Tool activity is recorded with sensitive argument redaction, request correlation IDs, centralized export hooks, and connector lifecycle audit events for connect, resolve, refresh, revoke, and reconnect-required transitions.
Model-facing response safety
Tool output is sanitized before it reaches the model, large responses are capped, and sensitive URL query parameters such as tokenized or signed download links are redacted before they can leak into logs or model context.
Release and CI hygiene
Security regression tests, dependency audit, Bandit static analysis, SBOM generation, and release provenance attestation are defined in the repository so the hosted gateway has repeatable build and release checks.
Tenant-aware connector guardrails
The live connector architecture requires explicit tenant context for multi-tenant write operations, while approved read and search workflows can remain broader only when they are clearly non-mutating.
Control Boundaries
- Customers control Smplify account permissions and which trusted MCP clients their users authorize.
- Smplify operates the hosted gateway controls that protect the shared service, including OAuth 2.1 connector auth, rate limiting, monitoring, HTTPS enforcement, and URL-token exposure blocked by default.
- The hosted service executes requests only with a Smplify-issued MCP token backed by a server-side encrypted connector bridge, so access remains scoped to that customer’s Smplify permissions.
- OAuth-connected clients validate against
auth.smplify.com, and any temporary upstream bearer-token bridge remains encrypted with AWS KMS, revocable, server-side only, and tracked through an explicit upstream session lifecycle.
Recommended Customer Practices
- Authorize only trusted MCP clients and request only the scopes needed for the workflows you want to enable.
- Remove stale client authorizations and reconnect promptly when the gateway reports that an upstream session is expiring.
- Require human approval for destructive or administrative workflows such as device lock, wipe, unenroll, policy changes, and tenant configuration updates.
- Revoke the affected authorization promptly if a device or workstation may have been exposed.