AgentArmorHQ
Sign in
Permissions and access

Require an API key before exposing an MCP HTTP-stream server

AgentArmor team2 min read

You will start your PraisonAI MCP HTTP-stream server only with an explicitly set API key and confirm that unauthenticated requests are rejected. This closes a gap where an unset key left the server open to callers.

  1. Upgrade praisonaiUse 4.6.78 or later
  2. Set an API keyPass it explicitly, never rely on the default
  3. Bind to localhostExpose remotely only behind TLS
  4. Test rejectionUnauthenticated requests must fail

Why it matters

PraisonAI's MCP HTTP-stream server only checked authentication when an API key was configured, and the CLI defaulted --api-key to None, so a plain serve command left it open (GHSA-hc5v-gxvj-58wh (opens external site)). Anyone who could reach the port could enumerate tools and send tool-call arguments that were not validated against their input schema. This was rated CVSS 7.3 (GHSA-hc5v-gxvj-58wh (opens external site)), and the fix shipped in praisonai 4.6.78 (GHSA-hc5v-gxvj-58wh (opens external site)).

Steps

  1. Upgrade praisonai to 4.6.78 or later before you run any HTTP-stream server.
  2. Generate a long random key and store it in your secret manager or an environment variable, not in a script, a committed config file, or shell history.
  3. Start the server with the key passed explicitly through --api-key instead of relying on the default, which is None:
praisonai mcp serve --transport http-stream --api-key <your-key>
  1. Bind the server to localhost unless remote clients truly need it. If they do, put a TLS reverse proxy in front of it and keep the key check enforced at the server.
  2. Send a request without the key and confirm it is rejected. Then send one with the correct key and confirm it succeeds.
  3. Limit the tools the server exposes to what your clients actually call, so a misused call has a smaller blast radius.
  4. If the server ever ran without a key on a reachable network, treat that key as compromised, rotate it, and review which tools were called.

Common mistakes

  • Assuming an internal host is protected. Any reachable port can be used by anyone on that network.
  • Dropping the key flag from a deployment script after an upgrade, which quietly returns you to the unset default.
  • Storing the key in a systemd unit or config file that other users on the machine can read.
  • Checking the key only at startup instead of on every request.

Checklist

0 of 8 done

Sources

  1. GitHub Advisory Database: GHSA-hc5v-gxvj-58wh
Was this guide useful?