MCP authentication
Tenant-bound OAuth, mTLS sender constraints, token exchange, scopes, and credential handling for Lattix MCP.
Lattix MCP is an OAuth resource server with a dedicated audience. The exact
audience is published by your deployment; the standard registration name is
api://lattix-platform-mcp. The base scope is mcp.access.
Tenant binding
The access token must contain a valid tenant claim, subject, expiry, issuer, audience, and scopes. The server derives tenant identity only from the verified token. Tool arguments and caller-provided headers cannot select or override a tenant.
Production tokens are sender-constrained with cnf.x5t#S256. Present the
matching client certificate during TLS negotiation. Do not send certificate
identity headers yourself; when a reverse proxy is used, only the trusted local
proxy may set the verified thumbprint header.
Separate downstream token
The MCP token is valid only for the MCP resource. The server uses OAuth 2.0
token exchange at the configured authorization server to obtain a distinct,
short-lived token for api://lattix-platform-api.
This separation prevents token passthrough and confused-deputy behavior. The
exchange must preserve the tenant, and the downstream token can contain only
the Platform API scopes required for the operation. The Platform API itself
still receives bearer tokens exactly as described in Platform API
authentication; it does not accept client secrets or
MCP tokens on /v1/sdk/* routes.
Scope model
All MCP calls require mcp.access. Every public tool also requires
platform-api.access, plus operation-specific scopes:
| Capability | Scope |
|---|---|
| Resolve policy | policy.read |
| Compute protection or key guidance | crypto.use |
| Use the TDF profile | tdf.wrap |
| Register artifact metadata | content.write |
| Record enforcement evidence | control.write and content.write |
The server checks scopes before invoking the Platform API, and the Platform API checks them again. Missing, malformed, expired, wrong-audience, wrong-certificate, or cross-tenant credentials fail closed.
Credential hygiene
- Store OAuth client credentials and certificate private keys in an approved secret manager.
- Never place tokens, secrets, or private keys in prompts, tool arguments, source control, logs, or artifact metadata.
- Use short token lifetimes and rotate client credentials and certificates according to your tenant policy.
- Treat repeated authentication failures or tenant-binding mismatches as security events.