GHSA-jxcw-qp4h-6jfq

## Summary The published A2U advisory `GHSA-f292-66h9-fpmf` says unauthenticated A2U event streaming was fixed in `praisonai` `4.5.115`. Current head still exposes the same A2U subscription and event routes without authentication when the operator starts the documented CLI entrypoint: ```text praisonai serve a2u --host 0.0.0.0 --port 8002 ``` The current CLI wrapper does not expose `--api-key`, does not install the common API-key middleware, and does not generate a token for A2U. It calls `create_a2u_routes(app)` directly. That helper only enforces auth if `A2U_AUTH_TOKEN` is already present; if the variable is missing, `_authenticate_request()` returns `None` and treats auth as disabled. This is an incomplete-fix report for the published A2U issue, not a separate trust-model-only concern. ## Technical Details The Typer command for A2U accepts only `--host` and `--port`: ```text src/praisonai/praisonai/cli/commands/serve.py:570-585 ``` It forwards only those values to the shared serve handler: ```python args = ["a2u", "--host", host, "--port", str(port)] ``` The serve handler for A2U likewise accepts only `host` and `port`, then creates the app: ```text src/praisonai/praisonai/cli/features/serve.py:802-817 ``` `_create_a2u_app()` registers A2U routes directly: ```text src/praisonai/praisonai/cli/features/serve.py:827-853 ``` No call to `_install_api_key_middleware(app, ...)` is made for the dedicated A2U server, unlike the unified server path. Inside `create_a2u_routes()`, auth is opt-in: ```text src/praisonai/praisonai/endpoints/a2u_server.py:245-253 ``` ```python auth_token = os.environ.get("A2U_AUTH_TOKEN") if not auth_token: # No token configured - auth disabled (development mode) return None ``` The route helper then registers the same sensitive endpoints from the public advisory: ```text src/praisonai/praisonai/endpoints/a2u_server.py:391-409 ``` ### Why This Is Not Intended Behavior The public advisory for `GHSA-f292-66h9-fpmf` de