# 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.