Affected: MervinPraison PraisonAI

PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.51, praisonai serve agents parses config["api_key"] but _create_agents_app() does not authenticate POST /agents or POST /agents/{agent_name}. Missing or incorrect bearer and X-API-Key values still reach agent execution. This issue is fixed in version 4.6.58.

Affected: PyPI: PraisonAI

### Summary `praisonai serve agents` exposes HTTP routes that invoke registered agents. The CLI advertises `--api-key` with help text "API key for authentication", parses it, and forwards it into `ServeHandler`. But `_create_agents_app()` **never reads `config["api_key"]` again** and installs no auth dependency or middleware on its direct routes. The configured key is a no-op flag. As a result, an unauthenticated network caller can invoke exposed agents (`POST /agents` and `POST /agents/{agent_name}`) even when the operator passed `--api-key`. Requests with no credentials, a wrong `Authorization: Bearer`, a wrong `X-API-Key`, or an empty bearer all reach `agent.start()`. The failure is made sharper by the fact that a **working auth dependency already exists in the same module** — `praisonai.api.agent_invoke.verify_token` guards every `/api/v1/...` route with `Depends(verify_token)` and is mounted into the very same app. The direct n8n-compat routes simply do not use it.

## Technical Detail ### Source-to-sink trace **1. CLI advertises and forwards `--api-key`:** ```python # cli/commands/serve.py @app.command("agents") def serve_agents(..., api_key: Optional[str] = typer.Option(None, "--api-key", help="API key for authentication")): ... if api_key: args.extend(["--api-key", api_key]) exit_code = handle_serve_command(args) ``` **2. `cmd_agents()` parses `api_key` into the spec — and that is the last time it is touched:** ```python # cli/featur…