Transport security & the node WAF
Every request into System9 arrives over a guarded transport and passes the single front door (the node gateway) before it reaches a service. Between cells the channel is mutual TLS with identity carried in the client certificate; at the front door a web application firewall and a stack of gateway guards inspect the request; and a threat-level enforcer tightens the whole surface automatically when the platform's own detection pipeline raises the posture. Transport security is not a perimeter appliance bolted on. It is part of how cells identify each other and how the gateway admits a request.
In one paragraph
Cells authenticate each other by mutual TLS with identity in the certificate; the single front door runs a regex-ruleset WAF, egress and inbound guards, rate limiting, and request signing; and a threat-level enforcer raises the bar across all of it when detection raises the posture.
The controls
| Control | What it does |
|---|---|
| Mutual TLS between cells | Both ends present certificates; the peer's identity is carried in the client certificate, so a cell knows which cell it is talking to, not just that the channel is encrypted. |
| Authenticated clear channels inside a cell | In-cell traffic is authenticated even where it is not TLS-wrapped. |
| SPKI pinning | The expected public-key identity is pinned, so a substituted certificate is rejected. |
| Web application firewall | Configurable regex rulesets (SQL injection, XSS, path traversal, protocol abuse) matched against request path, query, and headers; a match returns 403. Rulesets are individually enable/disable-able. |
| Inbound / outbound guards & egress URL guard | Guards on both directions, with an explicit guard on outbound egress URLs. |
| IP allow/deny & geo filtering | Network-level admission by address and geography. |
| Rate limiting & circuit breaking | Per-client and per-endpoint rate limits, plus circuit breaking under load. |
| Request signing & content-type validation | Requests are signed; content types are validated; a dynamic denylist and security headers apply. |
| Threat-level enforcer | Tightens access automatically when the platform's own detection pipeline raises the posture: the perimeter responds to the platform's own signal. |
One front door, guards in series, posture-aware
A request runs a series of gateway guards before it reaches a service, and the strictness of that series moves with the platform's own threat posture, a raised posture tightens the same door that was already inspecting the request.
*Figure: one guarded front door, posture-aware. A peer authenticates by mutual TLS with SPKI pinning and identity in the certificate; the node gateway runs network filters, a regex-ruleset WAF, and inbound/outbound guards with request signing before a request reaches a service; and a threat-level enforcer raises the strictness across every guard when the platform's own detection raises the posture.
Table equivalent
| Layer | Control | On failure |
|---|---|---|
| Channel | Mutual TLS + SPKI pinning (identity in cert) | Connection refused |
| Network | IP allow/deny, geo filter, rate limit, circuit breaker | Throttled or refused |
| Application | WAF regex rulesets | 403 Forbidden, recorded |
| Request | Inbound/outbound guards, egress URL guard, request signing, content-type validation | Refused |
| Posture | Threat-level enforcer | Tightens all guards automatically |
The cell backplane
The front door is one half of transport security. The other is what cells say to each other, and it is governed differently because the threat is different: a peer cell is not an anonymous client, it is a participant that must prove which participant it is.
Every inter-cell call is mutually authenticated. A cell holds its own cell identity key, and identity is carried in the client certificate rather than in a header a caller supplies. There is no inter-cell call that is unauthenticated.
| Property | How it works |
|---|---|
| Mutual TLS on every hop | Both ends present a certificate; the caller's identity is the certificate, not an assertion inside the request |
| gRPC as the backplane transport | Cross-cell replication, repair, distributed query fragments and workflow dispatch ride gRPC under mutual TLS |
| A cell binds no principal | A cell acts for no entity. It is infrastructure, and its leaf is signed by the node intermediate above it |
| An identity snapshot | Presented and validated on every inter-cell call rather than resolved once and cached indefinitely |
| Peer snapshots trust the certificate | A peer's reported state is trusted on a verified mutual-TLS certificate identity, not a self-asserted header |
| SPKI pinning | Where the peer's key should not change, it is pinned |
Inside a cell, callers reach services over an authenticated clear channel on loopback. Backend services bind loopback for local callers and a mutual-TLS port advertised on the fabric for peers, and neither is an external surface. External traffic reaches them through the node gateway or not at all.
The practical consequence is that the estate can be many cells without the trust between them being assumed. A cell that cannot present a valid identity does not get a degraded conversation; it does not get one.
Why it is different
- The certificate carries identity, not just encryption. Mutual TLS with identity in the client certificate means a cell authenticates which peer it is talking to, the same entity model that governs everything else.
- The perimeter responds to the platform's own signal. The threat-level enforcer raises access strictness when detection raises the posture, so the door tightens without a human turning a knob. See threat detection.
- It is the single front door. The node gateway is where these guards compose, so a request cannot reach a service by an unguarded side path. See the node service.
Across the deployment matrix
- Single-cell, the gateway and WAF guard the cell's front door; in-cell channels are authenticated.
- Multi-cell, mutual TLS with identity in the certificate is how cells authenticate each other across the fabric.
- Sovereign / air-gapped, every control evaluates locally; there is no external WAF service or certificate authority in the request path.
- Cloud-enabled, identical controls; egress URL guarding applies to outbound cloud calls.
Related
- Identity & Access, the entity model the client certificate carries.
- The net-effect gate, the action-boundary decision beyond the transport.
- Threat detection, the detection pipeline that drives the threat-level enforcer.
- Node service, the single front door the WAF runs in.