Pinecone API keys: per-project, env-only, rotate on exposure

API key discipline for Pinecone

The model

Keys are issued per project in the Pinecone console. A key from project A cannot touch project B's indexes; using it there gives 404s on indexes that "should exist" or a flat 401. When an agent reports a missing index, check the project before debugging the name.

Rules

1. Environment only. PINECONE_API_KEY in the shell, CI secret store, or hosting provider's secret manager. Construct clients with no arguments (Pinecone(), new Pinecone()) so there is no key literal anywhere to leak.
2. One key per deployment context. Do not share a single key across local dev, CI, and production. Separate keys let you rotate one context without breaking the others.
3. Rotate on any exposure. If a key appears in a log, a pasted transcript, or a repo, revoke it in the console and issue a new one immediately. There is no "probably fine".
4. Name keys after their use (ci-rag-prod, local-dev) so a future rotation does not require guessing what each key feeds.
5. 401 means key trouble. 401 Unauthenticated: Your API key is missing or invalid (per the error-handling guide). Before retrying, verify the key value, the project it belongs to, and that it was not revoked.

Traps for agents

1. Passing the key as a function argument through three layers of helpers, where it ends up in an error message or a trace. Keep it at the process boundary.
2. .env files committed to git. Add them to .gitignore before the first commit, not after the leak.
3. Confusing the Pinecone API key with inference API keys or cloud provider keys in multi-service setups. Label every secret with its service.

Pinecone's manage-api-keys guide documents per-project keys created in the console. The error-handling guide defines 401 as missing or invalid API key. Both SDK READMEs document environment-variable construction. Verified against live docs 2026-09-26.