Kailash API Gateway Ships Hardcoded JWT Secret in Public Repository, Enabling Token Forgery

A critical security vulnerability has been identified in Kailash's API Gateway middleware component, where a hardcoded default JWT signing key is embedded directly in publicly accessible open-source code. The finding, cataloged as F-C-35 during the Wave 5 portfolio specification audit, exposes a signing key measuring just 18 characters—significantly below the 32-byte minimum enforced by JWTConfig elsewhere in the same codebase. The vulnerable code resides in `src/kailash/middleware/communication/api_gateway.py` at lines 166 through 175, where `APIGateway(enable_auth=True)` instantiates a default `JWTAuthManager` using the plaintext secret `"api-gateway-secret"` when no explicit `auth_manager` parameter is provided.

The flaw creates an authentication bypass risk for any deployment relying on default configuration. Because the signing key exists in a public repository, any actor can generate structurally valid JWT tokens claiming arbitrary identity claims, effectively impersonating any user within the kailash-api audience. The 18-character length compounds the issue: not only is the key publicly known, but it also violates the project's own cryptographic standards, which mandate a minimum of 32 bytes for HMAC-SHA256 secrets. This means systems importing the module with authentication enabled and no custom configuration are operating with compromised security guarantees.

The expected remediation follows existing project guidelines documented in `rules/env-models.md`, which prescribe environment-variable-based secret management rather than embedded defaults. Until the hardcoded value is replaced with a runtime lookup, any production or staging environment inadvertently using the default risks unauthorized access. The exposure is particularly acute for automated builds and containerized deployments where configuration injection may be overlooked. Development teams should audit their `APIGateway` initialization calls to ensure an explicit `auth_manager` with a cryptographically random secret is provided, and avoid shipping applications that depend on the vulnerable default path.