AI Pilot — mTLS Enforcement

Audience: Security architects, platform engineers Time: ~6 min read

AI Pilot can enforce mutual TLS on the AI tier — the bouncer presents a SPIRE-issued SVID to every selected upstream and refuses to connect on any other path.

When to enforce mTLS

Upstream type	Recommended?	Notes
Internal LLM endpoints (self-hosted models)	strongly recommended	Pairs with workload identity
MCP servers (internal)	strongly recommended	Stops untrusted clients from impersonating MCP traffic
RAG services	strongly recommended	Embeddings/contexts often contain sensitive data
Internal APIs called by AI agents	strongly recommended	The classic Zero Trust path
External LLM providers (OpenAI, Anthropic, etc.)	not applicable	Providers terminate TLS server-side; bouncer uses standard TLS + bearer/api-key

Configure

Open Settings -> AI Pilot -> mTLS and toggle which upstream classes require it:

mtls_enforcement:
  required_for: ["llm-internal", "mcp", "rag", "api"]
  trust_bundle_ref: spire-trust-bundle
  fallback_action: deny      # deny | warn | allow

The bouncer reads SVIDs from the SPIRE Workload API socket (already provisioned when SPIRE is enabled). The compiler emits a BackendSecurityPolicy carrying the trust-bundle reference.

How identity flows end-to-end

Click to enlarge

The bouncer's identity is spiffe://<trust-domain>/bouncer/<bouncer-id>. Upstream services validate the SVID against the issued trust bundle.

Failure modes

Condition	Result with `fallback_action=deny`
SPIRE Agent socket missing	Connection refused; logs `MTLS_AGENT_UNAVAILABLE`
Trust bundle expired	Connection refused; logs `MTLS_BUNDLE_EXPIRED`
Upstream rejects SVID	Connection refused; logs `MTLS_PEER_REJECTED`

With fallback_action=warn, the bouncer emits the same audit events but allows the connection. Use only during onboarding.

Audit and visibility