Security Overview
Smplify MCP now runs an OAuth 2.1-first hosted integration flow for Claude, ChatGPT, and other remote MCP clients, while still supporting an advanced manual bearer-token path for developer tools. This page summarizes the live controls behind the production deployment that is serving those connection paths today.
https://auth.smplify.com with Smplify-issued MCP tokens. The hosted /setup portal still exposes the manual browser-direct sign-in path to api.smplify.com for advanced clients, while OAuth-connected clients use a private connector vault bridge with AWS KMS-backed envelope encryption and an upstream session lifecycle manager so bearer tokens stay server-side and expiring sessions can move from ACTIVE to EXPIRING_SOON to RECONNECT_REQUIRED without leaking credentials.
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 OAuth metadata on the MCP domain, including Dynamic Client Registration and protected-resource metadata.
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 can still fetch a bearer token with a browser-direct sign-in flow to api.smplify.com, or accept an existing bearer token manually. OAuth sign-ins run through auth.smplify.com, where Smplify issues audience-bound MCP tokens and keeps any temporary upstream bearer-token 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 the Smplify account permissions and any bearer tokens they generate, including token issuance, rotation, lifetime, and the underlying permissions in their own Smplify tenants.
- 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 is designed to execute each request with either the caller’s own bearer token or 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
- Prefer short-lived bearer tokens with only the permissions needed for the workflows you want to enable.
- Use trusted MCP clients and keep bearer tokens in header-based or environment-variable based setups whenever possible.
- Require human approval for destructive or administrative workflows such as device lock, wipe, unenroll, policy changes, and tenant configuration updates.
- Rotate tokens promptly if a device, workstation, or config file may have been exposed.