LLM API 401, 403 and 429 Errors Guide: Keys, Quotas and Abuse

A 401, 403 or 429 from a model provider looks like an availability problem, but each one is also a statement about the API key behind the call: whether it is valid, what it is allowed to do, and how much it has already spent. Teams that treat these responses only as outages retry them, rotate keys at random, or raise limits, and in doing so can miss a leaked key being abused. This guide covers the documented error responses of the OpenAI, Anthropic, Azure OpenAI and Google Gemini APIs, ranks the likely causes of each, shows where to look, and separates the fixes from the signals that a key has been stolen. It is for platform engineers, AI application developers and security teams who own model provider credentials. Key protection itself is covered in the LLMjacking Guide. Error strings and headers were checked against provider documentation on 11 November 2026; providers change them, so re-check before relying on an exact string.

Key takeaways

• Read the body, not just the status. One 429 can mean "slow down" or "out of money", and only the error type, code and headers tell you which. Retrying a spend or quota 429 never succeeds.
• 401 is about the credential, 403 about the context. 401 means the key, organisation or source IP is not accepted; 403 means the key is recognised but the project, region, model or permission is not allowed.
• Retries can make it worse. OpenAI and Azure both state that failed requests still count toward per-minute limits; stacked SDK and application retries multiply load.
• Unexpected 429s are a security signal. A key that hits its limit or spend cap without a matching change in your own traffic may be in someone else's hands. Check usage by key before raising limits.
• Leaked keys are blocked. Google documents a specific message for keys reported as leaked. The fix is a new key and removing the old one from wherever it was exposed, not a support ticket.

How the three codes differ

Provider error reference

Strings are quoted from each provider's documentation as checked on 11 November 2026.

Anthropic's documentation also lists a user-set spend limit returned as 400 invalid_request_error with a message beginning "You have reached your specified API usage limits", so a spend problem does not always arrive as a 429. Every Anthropic error body includes a request_id, also returned in the request-id header; record it for support and for correlation.

Diagnosing 401: the credential is not accepted

Likely causes, most to least common:

1. The process loaded a different secret: an old value cached in a container image, a .env file overriding the secret manager, or the wrong environment's secret mounted. Log a short fingerprint (for example the last four characters or a hash) of the key at startup, never the key.
2. The key was rotated or revoked: by a teammate, by an automated rotation, or by the provider after a leak report. Check the provider console's key list and audit log for the key's status and last change.
3. Header or endpoint mismatch: OpenAI uses Authorization: Bearer; Anthropic uses x-api-key; Azure OpenAI uses an api-key header or Entra ID tokens against a resource-specific endpoint. A key sent to the wrong provider, region or resource endpoint returns 401.
4. Organisation or project scope: an OpenAI key used with an organisation header it does not belong to, or an account outside any organisation.
5. IP allowlist: new NAT gateway, a CI runner pool or a move to another region changed the source address.

Where to look: application startup logs (key fingerprint, endpoint, organisation header), the provider console's key list and last-used time, and egress IP from the workload. Fix: correct the secret reference in the secret manager and redeploy; do not paste a working key into code or CI variables as a stopgap. See the API Key Management Guide.

Diagnosing 403: valid key, wrong context

• Model or feature access: the project or workspace has not been granted the model, or the model was retired. Confirm the model identifier against the provider's current model list.
• Project restrictions: per-key permission settings (for example read-only or endpoint-restricted keys) block the call. Prefer narrowing a key to widening it: create a correctly scoped key for this workload.
• Location: OpenAI documents a 403 for unsupported countries, regions or territories, which can appear when a workload's egress moves.
• Billing tier: Google documents that a free-tier restriction returns 403 PERMISSION_DENIED and that the project must be linked to a Cloud Billing account; a new key in the same project does not help.
• Cloud IAM in front of the model: on Azure OpenAI and Vertex AI the caller may authenticate with a cloud identity instead of a key, and 403s then come from role assignments. Use the Azure AuthorizationFailed Troubleshooting Guide or the Google Cloud PERMISSION_DENIED Troubleshooting Guide.

Diagnosing 429: rate, quota or spend

Which limit was hit

Rate limit versus money limit

• Rate limit: transient. OpenAI's guidance is to retry 429 and 503 with exponential backoff and jitter, treat Retry-After as a minimum wait, cap attempts and total retry time, and not retry quota or billing errors.
• Spend or credit limit: persistent until a person acts. Anthropic documents that a platform spend cap 429 carries no retry-after and fails until access resumes at the start of the next month or the tier is raised; OpenAI returns credit_balance_exhausted.
• Burst shape: Azure evaluates RPM over 1 or 10 second windows, and Anthropic notes a 60 RPM limit may be enforced as 1 request per second, so a burst of parallel agent calls can be throttled even when the per-minute total is low.
• Tokens, not requests: large prompts exhaust TPM or ITPM with few requests. Prompt caching (where supported) and smaller contexts reduce token pressure more than request pacing does.

Retry hygiene

Choose one retry layer. Azure's documentation advises setting the SDK's max_retries to zero when you add your own retry library, and OpenAI warns that SDK retries plus application retries multiply requests. Agents add a third layer: a tool loop that re-plans after an error. Give each agent run a token and request budget and stop the run when it is exhausted.

When the error is a security signal

Stolen model provider keys are resold and used for high-volume inference, which surfaces to the owner as unexplained 429s, spend caps reached early, or a provider leak block. MITRE ATT&CK classifies this as T1496.004 Cloud Service Hijacking, and the theft itself as T1552.001 Credentials In Files when keys are taken from code or configuration. The OpenCode console breach is a recent case of stored OpenAI, Anthropic and Google keys being stolen and abused.

Response steps are in the LLMjacking Response Playbook and the AI model provider API keys leak response guide.

Fixing without creating new risk

1. Classify first: record status, error type or code, request ID and rate limit headers for the failing call.
2. For 401 and 403: fix the secret reference, endpoint or scope; if a key must be replaced, create the new key, deploy it, confirm traffic on it, then revoke the old one.
3. For rate 429: add jittered backoff in one layer, reduce concurrency, cache prompts, then request a higher tier if demand is genuine.
4. For spend 429: compare provider usage by key with your own logs before adding credit or raising a cap. If they disagree, treat it as a suspected compromise.
5. Test in a staging project: with its own key and low limits, so throttling behaviour can be exercised safely.
6. Roll back: keep the previous key valid only for the short overlap window and the previous limit configuration recorded, so a bad deployment can be reverted without re-issuing secrets.

Routing all calls through an AI gateway gives one place to enforce per-application budgets, map provider errors to consistent internal codes and hold provider keys away from application code. See the AI Gateway and LLM Gateway Guide and How to Set spend limits on llm api keys.

Detection and measurement

• Log per call: application, key fingerprint, model, status, provider error type or code, request ID, tokens in and out, and the remaining-limit headers.
• Reconcile daily: provider console usage by key against your own logged tokens; a gap is the strongest early indicator of key misuse.
• Alert: on spend cap or credit exhaustion events, on any leaked-key response, and on 401 rates above baseline after a rotation window closes.

Common failure patterns

• Retrying a spend limit: SDK retries hammer an endpoint that cannot succeed until a person acts.
• Raising limits before checking usage: a higher cap gives an attacker using a stolen key more room.
• One key for everything: every application shares a key, so one leak or one runaway loop stops all of them and usage cannot be attributed.
• Rotating by deletion: revoking the old key before the new one is deployed causes a self-inflicted 401 outage.
• Logging full keys while debugging 401s: the fix creates a new exposure in log storage.
• Ignoring 403 on retired models: agents silently fail over to more expensive models or stop working.

Framework mapping

Practitioner checklist

• Capture status, error type or code, request ID and rate limit headers for every failed call.
• Distinguish rate limits from spend and credit limits in code, and never retry the latter.
• Use one retry layer with jittered backoff and a cap on attempts and total time.
• Give each application its own key with a named owner, scope and spend limit.
• Rotate by overlap: deploy the new key, confirm, then revoke the old.
• Reconcile provider usage per key with internal logs daily.
• Treat leaked-key blocks and unexplained spend as incidents.
• Budget tokens and requests per agent run.

Standards and references

• OpenAI: Error codes
• OpenAI: Rate limits
• Anthropic: Errors
• Anthropic: Rate limits
• Microsoft Learn: Manage Azure OpenAI quota
• Google AI for Developers: Gemini API troubleshooting
• OWASP: LLM10:2025 Unbounded Consumption
• MITRE ATT&CK: T1496.004 Cloud Service Hijacking

Related NHI Mgmt Group resources: LLMjacking Guide, OpenAI API Keys Security Guide, Anthropic API Keys Security Guide, Rate Limiting and API Abuse Guide, AI Gateway and LLM Gateway Guide.