A Kimi K3 API key should be treated like a production secret from the moment it is created. The setup is simple, but the operating habit matters.
Create the key in the official console
Use the Kimi Open Platform account flow to create an API key. Keep the key out of source control, screenshots, shared notes, and frontend bundles.
If you are testing locally, store it in an environment variable such as MOONSHOT_API_KEY. If you deploy to a hosting platform, use that platform's secret manager rather than checking a .env file into Git.
Test the key with a small request
Before connecting Cursor, Claude Code, a gateway, or your application, send a minimal chat request directly to the Kimi API. This separates authentication problems from tool configuration problems.
After the request succeeds, check the provider console or logs to confirm the request was billed or recorded under the expected account.
Rotate and scope operational access
Use separate keys for local development, staging, and production when possible. If a key leaks, revoke it quickly and rotate the dependent service.
For team use, document who owns the key, where it is stored, which app uses it, and how to disable it during an incident.