Data Protection

Altuur Secure Ingress processes request traffic at the edge and stores identity data in the control plane. This page describes what data Secure Ingress handles, how it is protected, and what remains outside the platform’s scope.

What data flows through Secure Ingress

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 Secure Ingress, 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. Secure Ingress does not persist request or response bodies by default; traffic flows through the platform and is delivered to the workload. There are three exceptions, each limited in scope and retention: logging that you explicitly configure, data that you submit to us for support, and temporary capture during a security investigation permitted by our agreement with you or required by law. The Privacy Policy and the Terms of Service describe these exceptions and the retention that applies to them.

Identity data (control plane)

When authentication is enabled, Secure Ingress 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 Secure Ingress does not access

The outbound-only architecture creates a clear boundary between the platform and your infrastructure:

• Application data: Secure Ingress 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; Secure Ingress 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 Secure Ingress architecture is encrypted in transit:

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 public inbound origin required

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.

Secure Ingress removes the need for a public origin:

• Your workload does not need a public IP address
• No DNS record has to point to the workload
• No certificate has to be issued for the workload’s own hostname, so nothing references it in certificate transparency logs
• The edge reaches the workload only through the mTLS tunnel from Warpgate

This holds when the edge is the only route in. Adding Warpgate does not remove a public IP, listener, or firewall rule that already exists; close or firewall those so that no alternative path to the workload remains. See Close the direct path.

Privacy principles

Secure Ingress follows these data handling principles:

• Minimum data retention: request and response bodies are not persisted by default; the only exceptions are the explicitly configured logging, support submissions, and security-investigation capture described above, each limited in scope and retention
• 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