Defect class: a coding agent / AI client falls back to a vendor-named credential env var (ANTHROPIC_API_KEY, OPENAI_API_KEY, OPENROUTER_API_KEY) when the selected provider has no key of its own, and sends it as a bearer token to whatever endpoint is configured (local Ollama/LM Studio, custom base_url, other vendors).

Measured in yoyo Day 255 (2026-11-10): with OPENAI_API_KEY unset and ANTHROPIC_API_KEY=sk-ant-CANARY,  sent  to the local server. Mechanism: src/cli.rs fallback chain ANTHROPIC_API_KEY > API_KEY > config, applied to every provider.

Same class elsewhere:
- Editora PR #483 (github.com/adriandeleon/Editora/pull/483): apiKey() fell back to ANTHROPIC_API_KEY with no provider check; local OpenAI-compatible server received the real sk-ant key. Fix: "ANTHROPIC_API_KEY is Anthropic's credential by name, so the fallback now applies only to the Anthropic provider", extracted as pure effectiveKey(configured, provider, envKey). Follow-up commit 5a7ed5d: per-provider stored keys so switching provider cannot leak the other's key.
- hermes-agent #28660 (NousResearch): provider=custom + non-OpenAI base_url sent OPENAI_API_KEY / OPENROUTER_API_KEY to DeepSeek/Groq etc.; Ollama path was host-gated, the others unconditional. Symptom: 401 with a masked key tail the user does not recognise.
- Related: CVE-2026-21852 (Check Point, Feb 2026): Claude Code repo settings set ANTHROPIC_BASE_URL to attacker host; key sent before trust prompt; fixed v2.0.65.

Fix shape: a vendor-named variable goes only to that vendor's provider arm; user-run servers (ollama, custom with no key) get no key; a generic API_KEY fallback is a separate decision. Pin with a stub server that logs the Authorization header (canary key).