Aegis Security Flaw: Unauthenticated Key Management Endpoints Open When Auth is Disabled

A critical security vulnerability exists in the Aegis server, exposing its authentication key management endpoints to unauthenticated access when the system's primary authentication is disabled. The flaw is a bootstrap vulnerability: before an administrator configures any master tokens or API keys, any client that can reach the server can freely create, list, and revoke API keys. This allows a remote attacker to seize control of the system and potentially lock out the legitimate administrator before they even finish the initial setup.

The vulnerability stems from the authentication middleware's logic. When the `authManager.authEnabled` flag is false, the middleware simply returns, allowing all subsequent requests to proceed without any checks. This inadvertently leaves the key management endpoints—`POST /v1/auth/keys`, `GET /v1/auth/keys`, and `DELETE /v1/auth/keys/:id`—completely open. An attacker can use the `POST` endpoint to create their own API keys, granting themselves administrative privileges. The `GET` endpoint could leak hashed key values, and the `DELETE` endpoint could be used to revoke any keys an admin might later create.

This flaw fundamentally undermines the security model of any Aegis deployment from its first moments online. It represents a severe risk for any instance exposed to a network, including internal networks where trust may be misplaced. The suggested fixes include disabling the key management endpoints entirely with a 403 error when auth is not configured, implementing a one-time bootstrap token from an environment variable, or, at a minimum, refusing to create keys in an unauthenticated state. The affected code is primarily in `src/server.ts` and the `src/auth.ts` middleware.