> ## Documentation Index
> Fetch the complete documentation index at: https://docs.egisai.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Cloud-hosted interception (design, deferred)

> The future model where Egis holds a per-customer, name-constrained sub-CA in an HSM so a device fleet can be governed without running an on-prem node. Documented for review — not yet built.

<Warning>
  This page describes a **deferred design**, not a shipped feature.
  Today the [egress node](/coverage/egress-node) terminates TLS on
  hardware the customer controls, and its CA private key never leaves
  that box. The model below moves the crown-jewel key into Egis-run
  infrastructure, so it ships only behind its own security review. It
  is written down so that review has something concrete to start from.
</Warning>

## Why this exists

The on-prem node is the right default: the key that can mint
certificates for a customer's traffic lives on the customer's own
machine, and nobody at Egis can use it. But some customers want the
Zscaler/Netskope shape — no box to run, every laptop forwards to a
vendor-run cloud that terminates TLS. That convenience has a hard
requirement: Egis would hold a key capable of impersonating AI
providers for that customer's fleet. The design has to make misuse of
that key impossible by construction, not merely against policy.

## The shape

Per **customer**, a **name-constrained sub-CA**:

* **Non-extractable private key in a KMS/HSM.** Generated inside a
  FIPS 140-2/3 Level 3 module with `CKA_EXTRACTABLE = FALSE` and
  `CKA_WRAP_WITH_TRUSTED = TRUE`, accessed over PKCS#11. The key
  material never exists in application memory; signing is an HSM
  operation, not a library call.
* **Name-constrained to AI-vendor domains, path-length 0.** The same
  critical `NameConstraints` control the on-prem CA already carries —
  a leaked or subpoenaed intermediate cannot impersonate anything but
  the governed providers, and cannot issue further CAs.
* **Per-tenant isolation.** One sub-CA per customer, so a compromise
  or revocation is scoped to one tenant. No shared signing key across
  customers, ever.
* **Signing audit + attestation.** Every issuance is logged with the
  requesting tenant and the SAN; the customer can download an
  attestation of the HSM configuration (module, FIPS level, extractable
  flags) to satisfy their own auditors.

This matches how Zscaler and Netskope hold intermediate CAs for TLS
inspection: the tenant's signing key lives in the vendor's HSM, boxed
by name constraints, with an audit trail.

## What stays the same

* **Governance.** The same two-phase engine, deterministic-before-LLM,
  fail-closed on PII-engine error. Cloud interception changes *where*
  TLS is terminated, not *how* a call is judged.
* **Native forwarding.** The Gateway still governs each provider in its
  native shape; the cloud interceptor forwards exactly as the on-prem
  node does in `forwardTarget: egis` mode.
* **Owner attribution.** Identity still rides in `X-Egis-Person`,
  bound to the device's MDM-issued client certificate.

## What ships before it

Nothing in this page is on the near-term path. The prerequisites for
even starting the build:

1. A dedicated security review of the HSM key-custody model, including
   subpoena and insider-threat scenarios.
2. A per-tenant KMS/HSM provisioning and rotation runbook.
3. A signed attestation format customers' auditors will accept.

Until then, customers who need strict privacy run the on-prem node and
point `EGIS_GATEWAY_URL` at a [self-hosted](/operations/self-hosting)
backend — nothing leaves the building, and no Egis-held key can touch
their traffic.