Skip to main content
This page describes a deferred design, not a shipped feature. Today the 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.

​
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 backend — nothing leaves the building, and no Egis-held key can touch their traffic.