Security

The MCP endpoint can reach application behavior on behalf of a model. Treat its exposure, inputs, and credentials as production security boundaries.

Defaults

• Requests with an Origin header are rejected unless the origin is explicitly allowed.
• Tool input cannot set internal request headers by default.
• authorization, cookie, and x-api-key pass through from the inbound MCP request so existing Elysia auth hooks still run.
• set-cookie, cookie, and authorization are redacted from returned HTTP metadata.
• Binary responses fail unless marshal.binary is set to base64.
• Common documentation endpoints, hidden routes, and the MCP endpoint itself are not silently exposed.

Allow browser origins

mcp({
  transport: {
    validateOrigin: true,
    allowedOrigins: ['https://console.example.com']
  }
})

Do not disable origin validation just to make a browser client connect. Add the exact trusted origin instead.

Keep model-controlled headers narrow

mcp({
  headers: {
    passThroughFromMcpRequest: ['authorization'],
    allowFromToolInput: ['x-request-id']
  }
})

allowFromToolInput gives the model control of specific headers. Never add credentials, cookies, forwarding headers, or authorization inputs unless that behavior is intentionally part of the tool contract.

Restrict production routes

Prefer an allowlist for production APIs:

mcp({
  allowedRoutes: [
    { method: 'GET', path: '/customers/:id' },
    { method: 'POST', path: '/reports/preview' }
  ]
})

Use tool annotations to describe risk, but do not treat annotations as authorization. Authentication and authorization must remain enforced by Elysia hooks and guards.