Affected: MervinPraison PraisonAI

PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.58, create_auth_middleware() allows requests when auth=api-key lacks PRAISONAI_API_KEY or JWT authentication lacks PRAISONAI_JWT_SECRET. An externally bound Recipe server can therefore accept unauthenticated POST /v1/recipes/run requests despite authentication being enabled. This issue is fixed in version 4.6.58.

Affected: PyPI: PraisonAI

### Summary

The PraisonAI Recipe HTTP server silently allows unauthenticated requests when `auth` is configured as `api-key` or `jwt` but the corresponding secret is missing.

This creates an authentication fail-open condition. An operator can start the Recipe server with authentication enabled, including on a non-localhost interface, but the server still accepts unauthenticated requests if no API key or JWT secret is provided.

The issue is especially risky because the CLI safety check for non-localhost binding only verifies that `auth != "none"`. It does not verify that an actual API key or JWT secret exists.

### Details

The Recipe server documents the following authentication modes:

- `none` - `api-key` - `jwt`

Relevant source locations:

- `src/praisonai/praisonai/recipe/serve.py` - `src/praisonai/praisonai/cli/features/recipe.py`

In `create_auth_middleware()`, the API key middleware resolves the expected key as:

```python expected_key = api_key or os.environ.get("PRAISONAI_API_KEY")

if not expected_key: # No key configured, allow request return await call_next(request) ```

This means `auth: api-key` does not enforce authentication if `api_key` / `PRAISONAI_API_KEY` is missing.

The JWT middleware has the same fail-open behavior:

```python secret = jwt_secret or os.environ.get("PRAISONAI_JWT_SECRET") if not secret: return await call_next(request) ```

The auth middleware is still attached when `auth` is configured:

```python auth_type = config.get(…