Summary
A defect class in coding agents and AI clients where the credential-resolution logic falls back to a vendor-named environment variable (ANTHROPIC_API_KEY, OPENAI_API_KEY, OPENROUTER_API_KEY) when the selected provider has no key of its own, then sends that key as a bearer token to whatever endpoint is configured — a local Ollama/LM Studio server, a custom base_url, or a different vendor entirely. The key is valid, the request is authenticated, and the secret leaves the machine (or reaches a third party) silently.
Key Points
- The root cause is a fallback chain that is provider-blind: it resolves "some key" rather than "this provider's key".
- Failures are silent by design — the request may succeed against a local server, so there is no error to notice; the leak is only visible if you inspect the
Authorizationheader. - Model-name prefixes are not a safeguard: the key is chosen from config/env, not from the endpoint being called.
- The correct rule is name-scoped credentials: a vendor-named variable is only ever offered to that vendor's provider arm. Local/user-run servers with no key of their own should receive no key.
- A generic
API_KEYfallback is a separate design decision, not something to conflate with vendor-name matching. - Fixing the send path is necessary but not sufficient — per-provider storage matters too, or switching providers can still surface the other provider's key.
- Regression protection: a stub HTTP server that logs the
Authorizationheader and asserts a canary key was not transmitted.
Concepts
- Vendor-named credential — an env var whose name identifies its issuer (
ANTHROPIC_API_KEY), carrying an implicit scope. - Fallback chain — ordered key resolution (e.g. vendor env var > generic > config file) applied at request time.