Secure the complete boundary
Cheetah's production component constructor strengthens one layer. The deployed security boundary also includes the network edge, two client-facing transports, application and administrative identity, shared stores, optional payload storage, and product policy.
Every arrow that crosses the outer boundary needs an independently verified identity and transport decision.
Establish transport truth at the real edge
Client credentials travel in the WebSocket hello and in returned HTTP requests. Strict mode requires secure advertised HTTP service URLs and rejects a WebSocket whose external security is false or unknown.
Behind a TLS-terminating proxy, configure the transport adapter with trustworthy external scheme information. The supplied Starlette and aiohttp adapters do not trust forwarded headers by default. Trusting arbitrary client-supplied forwarding headers allows spoofing; ignoring a legitimate restricted proxy can make a secure connection appear insecure. Test the deployed proxy path, not only direct localhost traffic.
The WebSocket acknowledgement advertises the REST ingestion URL and optional service URLs to the client. Use addresses reachable from that client. Internal container names and plaintext development URLs are not suitable external advertisements.
Authenticate WebSocket and HTTP return separately
The WebSocket host authenticates connection setup and derives the effective principal. The application-owned HTTP edge must authenticate every returned message and pass its server-derived principal to the REST role. Never trust a user_id supplied only in the message body, and never treat an earlier WebSocket session as authentication for a new HTTP request.
Central authorization decides whether the application may request an action. The client then applies local policy and optional approval. Preserve both decisions and fail closed when a policy source is unavailable.
Protect operational authority separately
Diagnostics can reveal client identities, actions, pending work, retained payloads, contexts, and topology across users. The DevConsole control API can send real commands. Protect these surfaces with a deliberate administrative-authentication implementation and network access policy. Client authentication is not operator authorization.
The no-op admin provider is suitable only for a deliberately isolated local surface. The browser DevConsole cannot currently add the built-in X-Admin-Key header itself, so a deployed UI needs an authenticated gateway or session mechanism around it.
Align limits before traffic reaches Cheetah
Set compatible request-size and timeout limits at the proxy, HTTP framework, REST role, and payload store. RestNodeConfig.max_ingest_bytes bounds an incoming message before storage and correlation work. Large screenshots, DOM bodies, and parser results should use the supported payload mechanisms rather than an unbounded request limit.
Redis-backed command admission uses a resource quota for its per-scope backlog. This is not a universal customer quota or rate plan. The rate-limiter and audit-logger interfaces are not automatically invoked by ordinary node execution. Supply product and edge controls where the threat model requires them.
Configure CORS from the application's real browser and credential model. A token-protected endpoint does not make an unrestricted origin policy harmless, especially when product routes also use cookies.
Give secrets a lifecycle
Load authentication material, JWT keys, admin credentials, Redis credentials, payload-store access, and telemetry exporter secrets from the host's secret system. Keep them out of URLs, traces, diagnostic records, and handshake error text. Plan issuance, rotation, revocation, and offboarding rather than treating startup configuration as permanent.
Closing a user's current connections does not automatically purge retained history, deduplication state, product records, or exported telemetry. Define deletion and retention workflows for every store that carries the principal.
Treat shared tenancy as an end-to-end mode
The shared-tenancy constructor requires tenant-aware role configuration and validated components. The effective tenant/user principal must scope routing, history, correlation, notification, topology, cleanup, and application access.
This composition does not create organization provisioning, billing, per-tenant monitoring, support-access policy, or application-database isolation. Its current verified baseline also excludes active tracing, payload offload, central policy, the built-in parser registry, and Derived Views. Do not add one of these facilities to a shared deployment without a separately verified tenant-aware boundary.
See Identity and tenancy for canonical identity, the restricted application surface, component audit, and exact isolation limits.