Vault Key Limits Extended to MCP, Project Slugs Accepted
The vault-key attempt limit now covers the MCP tool surface as well as the web and CLI endpoints, and any API call may identify its project by slug instead of only by ID.
#What's Changed
- [Security] Extended the vault-key attempt limit to every MCP surface. The limit shipped in v1.5.0 covered the web and CLI key endpoints, but the MCP tools and the /api/mcp/v1 routes resolved vault keys on a separate path that was never throttled — leaving the online guessing path against the stored vault-key hash open to any authorized MCP client.
- [Improvement] Vault-key resolution now happens in a single place for the web, CLI and MCP alike, so a future endpoint cannot accept a vault key without also inheriting the attempt limit.
- [Improvement] Throttled key requests return a Retry-After header on the MCP routes too, and expose it to browser-based clients, so callers learn how long to wait instead of retrying blindly.
- [Fix] The X-Project-Id header and projectId query parameter now accept a project slug as well as a project ID. The CLI's --project flag,
apivault projects useand the CLI documentation all described this value as “project ID or slug”, but only an exact ID resolved — a slug returned “No project found”.