Skip to main content

How does Cipherscale work?

Rohit Kalbag
Updated

Cipherscale is an AI-native SSE platform that replaces network-based trust with identity, posture, and policy-based access, enforced at distributed gateways and operated primarily through a conversational AI Admin interface.

High-Level Architecture

Cipherscale’s architecture is built around the following principles:

  • Zero Trust by default – No implicit network trust; every request is authenticated, authorized, and evaluated continuously.

  • Control plane and data plane separation – Centralized intelligence with decentralized enforcement.

  • Identity-first access – Users, devices, and workloads are verified before access is granted.

  • Least privilege and explicit policy – Access is defined per resource, per user or group, under explicit policies.

  • AI-first operations – Configuration, troubleshooting, and visibility are driven by conversational AI rather than complex dashboards.

  • Cloud-native and multi-tenant – Designed for elastic scale, regional deployment, and tenant isolation.

Cipherscale is organized into five functional layers that decouple the decision-making "brain" from the traffic-handling "muscle."

Layer 1: Client Layer (The Agent)

The Agent resides on user devices (Windows, macOS, iOS, Android).

 It is responsible for:

  • Authenticating the user via the configured Identity Provider (IdP)

  • Establishing an encrypted WireGuard tunnel to Cipherscale Gateways

  • Collecting device posture signals (OS version, security state, compliance, etc.)

  • Enforcing local routing decisions provided by the Controller

Key characteristics:

  • Uses WireGuard® for high-performance, encrypted connectivity

  • No inbound ports are opened on the device, making it invisible to the public internet.

  • Supports split tunnel and full tunnel modes

  • Fails safely if the control plane is temporarily unavailable

Layer 2: Edge Layer (The Gateways)

Gateways are lightweight, cloud- or self-hosted edge nodes that act as the enforcement point between users and resources. Gateways can be deployed in your cloud (AWS, Azure, GCP) or on-prem via Docker/Linux. Multiple Gateways can be deployed for high availability and geographic proximity.

It is responsible for:

  • Terminating WireGuard tunnels from Agents

  • Enforcing Access Policies and Admission Rules

  • Performing DNS resolution and domain aliasing

  • Routing traffic to Private, SaaS, or Internet resources

  • Generating telemetry and audit logs

Layer 3: Control Plane (The Controller)

The central intelligence that does not sit in the data path. Because the Controller is separate from the data plane:

  • User traffic never passes through the control plane

  • Compromise or latency in the Controller does not directly expose workloads

Its responsibilities include:

  • Managing tenant configuration (users, groups, devices, resources)

  • Calculating who gets in based on identity and real-time device posture.

  • Distributing policy, routing, cryptographic keys, and configuration updates to Gateways and Agents

Layer 4: AI-native Administration & Agentic Workflows

The Administration portal is the primary interface for administrators. Instead of clicking through menus, you use natural language. It shows structured previews and asks for confirmations before applying any change 

Behind the scenes, LLMs handle intent and planning, while agentic workflows orchestrate multi-step tasks, and MCP (Model Control Plane) services perform the actual, bounded operations such as gateway provisioning, policy and routing changes, user and group management, and log/telemetry queries

All actions are validated, previewed, and fully auditable, and the strict separation between AI reasoning and deterministic MCP execution ensures safety, predictability, and compliance.

Layer 5: Data & Intelligence

Cipherscale continuously collects:

  • User session logs

  • Gateway activity and health metrics

  • DNS, routing, and access decision logs

  • Administrative and configuration events

Logs are streamed to a centralized Data Warehouse for analytics and audit.

Strict tenant-scoped data is provided to the AI Administration to provide "why" answers, not just "what" data.

End-to-End Access Flow

To get a better understanding of how it all works. Let us consider an example. The Admin has configured a private resource, a SaaS application, and three Gateways by using the Administration portal as follows:

Private resource: A private application called privateapp.local running on a server at 192.168.1.10. The DNS record for privateapp.local is configured on a private DNS server running on 192.168.1.1. The Gateway is deployed on the private network and has a private IP of 192.168.1.11 and a public IP of 173.70.130.198. The Gateway’s DNS server is configured as 192.168.1.1

SaaS application: One Gateway is deployed in San Francisco with a public IP of 66.249.68.32; another is in Boston at 146.75.252.1.  Both provide access to the SaaS application saasapp.com. Both Gateways are configured to use Google DNS servers 8.8.8.8

Access Policy: The access policy grants Admin access to all private resources and SaaS applications and is associated with the Admission Rule below.

Admission Rule: An Admission rule is configured to validate if the user's location is in the USA.

Here are the steps that the device, located in Boston, takes after the admin signs in using the cipherscale app and tries to access privateapp.local and saasapp.com:

  1. The user authenticates their identity after entering the Cipherscale Space.

  2. Upon successful authentication, the device establishes a control channel over HTTPS to the Cipherscale Controller.

  3. The device collects device posture data and sends it to the Controller. Note: The device will periodically send this information when it detects a change or upon the Controller's request.

  4. The device receives the IP addresses of the Gateways (66.249.68.32, 146.75.252.1, 173.70.130.198) associated with authorized applications from the Controller, along with the necessary keys to establish WireGuard connections. 

  5. Separately, the Controller pushes the policies and keys for the device that has joined the Cipherscale Space to the appropriate Gateways.

  6. The device calculates the round-trip time (RTT) to all provided Gateways to determine the optimal Gateway to use when multiple Gateways are available for the same destination.

  7. The device establishes the WireGuard tunnels to the Gateways.

    Note

    The Gateway in Boston is chosen for SaaS access based on the RTT measurements made by the device to it and the Gateway in San Francisco. The device now has simultaneous tunnels to two Gateways: one for the SaaS app and one for the Private app.

  8. The device intercepts and sends the DNS request for privateapp.local to the Gateway at  173.70.130.198 when the user tries to access it. 

  9. The Gateway then queries the upstream DNS server (in this case, 192.168.1.1) 

  10. The Gateway stores the returned IP address resolution and returns a private IP address within the CGNAT range instead of the destination IP addresses returned by the DNS server (192.168.1.10).

    Note

    The application server's true private IP address is not disclosed to the device. The gateway retains the mapping and routes packets to their final destination using NAT.

  11. The device transports data traffic to privateapp.local via the Gateway over the WireGuard connection. 

  12. The Gateway validates the conditions of the Admission Rule and the applicable Access Policy.

  13. Once the decision is made to allow the traffic, the Gateway configures firewall rules and routes the traffic to the destination.

  14. Next, the device receives the DNS request for saasapp.com when the user tries to access it. It forwards the DNS request to the Gateway.

  15. The Gateway resolves the DNS request using the configured DNS server 8.8.8.8 and responds with a private IP address within the CGNAT range instead of the destination IP addresses returned by the DNS server. 

  16. The device routes SaaS traffic to the Boston Gateway over the WireGuard connection. 

  17. The Gateway validates the conditions of the Admission Rule and the applicable Access Policy.

  18. Once the decision is made to allow the traffic, the Gateway configures firewall rules, employs NAT, and routes the request to the destination. 

  19. The servers for saasapp.com receive traffic with the Gateway’s IP address 146.75.252.1 as the source IP.

[1]


[1] "WireGuard" and the "WireGuard" logo are registered trademarks of Jason A. Donenfeld.

Comments

0 comments

Article is closed for comments.