Data Protection
Mezusphere processes request traffic at the edge and stores identity data in the control plane. This page describes what data Mezusphere handles, how it is protected, and what remains outside the platform’s scope.
What data flows through Mezusphere
Understanding what data the platform touches is the first step in evaluating its security posture.
Request traffic (data plane)
When end users access a service published through Mezusphere, the following data flows through the platform:
- HTTP request data: method, path, headers, query parameters, and request body
- HTTP response data: status code, headers, and response body
- Connection metadata: source IP, TLS version, protocol information
Request traffic is processed at the edge (for routing, authentication, and security enforcement) and forwarded to your Warpgate. Mezusphere does not persist request or response bodies. Traffic flows through the platform and is delivered to the workload.
Identity data (control plane)
When authentication is enabled, Mezusphere stores identity data in the control plane:
- User accounts: email, display name, status, login history
- User directories: organizational structure for user grouping
- Service accounts: API keys, permissions, project scope
- Session data: active authentication sessions
Identity data is encrypted at rest and accessed only through authenticated control plane APIs.
Configuration data (control plane)
Platform configuration is stored in the control plane:
- Projects and environments: organizational structure
- Routes and policies: traffic routing rules and authentication requirements
- Warpgate registrations: connection status, IP addresses, environment assignments
What Mezusphere does not access
The outbound-only architecture creates a clear boundary between the platform and your infrastructure:
- Application data: Mezusphere has no access to your databases, file systems, or internal state
- Source code: the platform does not inspect or store your application code
- Internal network: Warpgate connects outward; Mezusphere cannot initiate connections into your infrastructure
- Secrets and credentials: your application’s secrets remain in your environment; only the Warpgate token is shared with the platform
This boundary is architectural, not just policy-based. Because Warpgate initiates all connections outward, there is no mechanism for the platform to reach into your infrastructure.
Encryption
In transit
All traffic in the Mezusphere architecture is encrypted in transit:
| Connection | Encryption |
|---|---|
| End user → edge | TLS 1.2+ |
| Edge → Warpgate | TLS 1.3 with mTLS |
| Data plane ↔ control plane | TLS 1.3 |
There is no unencrypted traffic path in the platform.
At rest
Identity data, configuration data, and operational metadata stored in the control plane are encrypted at rest using industry-standard encryption.
No origin exposure
In traditional architectures, the origin server’s IP address can be discovered through DNS history, certificate transparency logs, or direct probing. Once discovered, attackers can bypass CDN or proxy protections and attack the origin directly.
Mezusphere eliminates this attack vector entirely:
- Your workloads have no public IP addresses
- No DNS records point to the workload
- No certificate transparency entries reference the workload
- There is no origin IP to discover
The workload is reachable only through the mTLS tunnel from Mezusphere’s edge. There is no alternative path.
Privacy principles
Mezusphere follows these data handling principles:
- Minimum data retention: request traffic flows through the platform without persistent storage of request or response bodies
- Purpose-limited access: identity data is accessed only for authentication, authorization, and account management
- Data ownership: your identity data belongs to you and can be exported or deleted
- Separation of concerns: identity data and platform configuration are stored separately from request traffic