LLM Base URL Override Security: OPENAI_BASE

One environment variable decides where an AI client sends its API key, prompts and source code, and whoever can set that variable can quietly redirect all three. LLM SDKs and AI coding tools let you override the provider endpoint with a base URL (OPENAI_BASE_URL, ANTHROPIC_BASE_URL, a base_url constructor argument or a gateway setting) so traffic can go through a corporate gateway, a regional endpoint, a local model server or a test stub. That flexibility is also an attack path: a malicious repository, a poisoned config file or a "bring your own endpoint" feature can point the client at an attacker's server, which then receives the authorisation header and every prompt. This guide explains where base URL overrides live, how they are abused, how to pin them centrally, how to validate user-supplied endpoints, and what to monitor. It is for platform, AppSec and developer-experience teams running AI SDKs, agents and coding assistants.

Key takeaways

The base URL is a security setting, not a convenience. It decides which server receives the API key or gateway credential and all prompt and file content, so changes to it need the same control as changes to a firewall rule.
Project-level config is untrusted input. CVE-2026-21852 in Claude Code showed a repository settings file setting ANTHROPIC_BASE_URL could send the user's API key to an attacker before the trust prompt; the fix deferred network calls until trust was confirmed.
Pin the endpoint from the top. Set the approved gateway URL in managed or system configuration that project files cannot override, and block direct egress to provider APIs from managed devices.
User-supplied endpoints are SSRF. Products that let customers enter an "OpenAI-compatible" URL must validate it like any other server-side fetch target, per OWASP API7:2023.
Keep the real provider key off the client. A gateway that holds the provider key and issues per-user credentials limits what a redirected client can leak.

Why endpoint overrides exist and where they live

Every major LLM SDK has a default endpoint and a way to change it. The reasons are legitimate: routing through an AI gateway for logging and cost control, using a regional or private endpoint, calling an OpenAI-compatible local server, or pointing tests at a mock. The OpenAI Python SDK, for example, documents a base_url constructor argument and the OPENAI_BASE_URL environment variable, alongside a custom HTTP client that can set a proxy. Claude Code documents ANTHROPIC_BASE_URL as the variable that points it at a gateway, with provider-specific variants such as ANTHROPIC_BEDROCK_BASE_URL.

Where the override is set	Typical example	Who can change it	Risk level
Code constructor argument	`OpenAI(base_url=...)`	Anyone who can change the code	Reviewed through normal code review, if reviewers know to look
Process environment	`OPENAI_BASE_URL`, `ANTHROPIC_BASE_URL` exported in a shell, container or CI job	Whoever controls the runtime, Dockerfile, CI variables or shell profile	High: invisible in code review, inherited by child processes
Project config file committed to a repository	`.env`, `.claude/settings.json` `env` block, IDE or agent config in the repo	Anyone who can commit, or anyone who sends you a repository	Highest: arrives with untrusted code
User-level config	`~/.claude/settings.json`, tool config in the home directory	The user, and any malware running as the user	Medium
Managed or system policy	Managed settings file or MDM policy	Administrators	Lowest: the right place to pin it
Product setting exposed to end users	"Custom OpenAI-compatible endpoint" field in a SaaS app	Customers, including malicious ones	High: server-side request forgery

See the Environment Variables and .env Files guide for why environment-based configuration is hard to govern.

How overrides are abused

Credential capture: the client sends its usual authorisation header to the overridden host. If the host is the attacker's, they receive the API key or gateway token and can spend against it or reach any data the key unlocks. ATLAS lists stolen credentials and cost harvesting (AML.T0055 Unsecured Credentials, AML.T0034 Cost Harvesting) among the outcomes.
Prompt and code exfiltration: every prompt, system prompt, tool result and attached file goes to the override. For coding agents that includes source code and anything the agent read from disk.
Response tampering: an attacker-controlled endpoint can return crafted completions or tool calls. If the agent acts on them, the endpoint effectively controls the agent, which is why OWASP LLM05 (Improper Output Handling) and LLM06 (Excessive Agency) still apply even when the "model" is fake.
Server-side request forgery: where an application lets users set the endpoint, the server makes requests to whatever URL is supplied, including internal services and cloud metadata addresses. OWASP API7:2023 lists user-supplied URLs in webhooks, file fetching and custom integrations as the common SSRF entry points.
Silent downgrade: a plain http:// base URL, or a client configured to skip TLS verification for a "local" endpoint, exposes keys and prompts on the network.

Case study: CVE-2026-21852 (Claude Code)

Check Point Research reported that a repository could include a .claude/settings.json file whose env block set ANTHROPIC_BASE_URL to an attacker-controlled host. Opening the project caused Claude Code to send API requests, including the user's API key in the authorisation header, before the user had answered the workspace trust prompt. According to Tenable's CVE record, published on 21 January 2026, Claude Code versions before 2.0.65 are affected. Anthropic's fix ensures no API requests are made until the user confirms trust,. Current Claude Code documentation states that most env values from a shared project settings file apply only after the folder is trusted. The lesson is general: any AI tool that reads endpoint settings from the project directory must treat them as untrusted until a human has accepted the project. See the Claude Code Security Guide and How to audit AI coding assistant tokens and config files.

Pinning the endpoint: architecture choices

Pattern	How it works	What it prevents	Trade-offs
Hard-coded default, no override	Application code sets the provider URL and ignores environment overrides	Environment and config-file redirection	Loses gateway flexibility; needs a code change to move providers
Managed policy pin	Admin-distributed settings set the approved gateway URL; tools refuse other values	Repository and user-level redirection on managed devices	Needs MDM or managed settings; only as strong as the tool's enforcement
Central AI gateway with per-user credentials	Clients hold short-lived gateway tokens; the gateway holds the provider key	Leak of the provider key; enables per-user revocation and logging	Gateway is critical infrastructure to operate and secure
Egress allowlist	Network or proxy only permits the gateway host; direct provider and unknown hosts blocked	Redirection to arbitrary hosts, and shadow AI use	Breaks legitimate local model servers unless allowlisted
Endpoint allowlist in application code	App validates any configured base URL against a fixed list of approved hosts and HTTPS	Mistyped or injected URLs in configuration	List must be maintained

Claude Code shows the managed-policy pattern concretely. Its documentation says managed settings sit above command-line, project and user settings, so nothing in a user's files overrides a managed key. To make a gateway the only destination, an administrator sets allowedProviders to ["customEndpoint"] in the managed settings file and puts the gateway's ANTHROPIC_BASE_URL in that file's env block; Claude Code then refuses sessions pointed anywhere else, including directly at Anthropic or at a developer's own proxy (documented as requiring v2.1.285 or later). The same documentation recommends issuing each developer their own gateway credential so offboarding revokes one credential. See the AI Gateway and LLM Gateway Guide and Agent Egress Control and Network Isolation Guide.

Validating user-supplied endpoints in your own product

If your product lets customers bring their own model endpoint, treat the field exactly like a webhook URL. OWASP API7:2023 recommends isolating the fetching mechanism, allowlisting where possible, disabling redirects, validating and sanitising input, and not returning raw responses to the client. Applied to model endpoints:

Require HTTPS and verify certificates; reject http:// outside an explicit local-development mode.
Resolve and check the address after DNS resolution, rejecting loopback, link-local (including cloud metadata such as 169.254.169.254), and private ranges unless the customer has a private connectivity arrangement. Re-check on each connection to defeat DNS rebinding.
Disable automatic redirects or re-validate each hop. The OpenAI SDK example for mTLS mode itself sets follow_redirects=False and states that X.509 requests must stay on the configured API origin.
Run outbound calls from an isolated egress path with no route to internal services.
Never forward your own provider key to a customer endpoint; the customer supplies their own credential, stored encrypted per tenant.
Bound and sanitise responses: size limits, timeouts, schema validation before tool calls are executed, and no raw error bodies echoed back to the user.

See the SSRF Prevention Guide and the OWASP API Top 10 API7 Server-Side Request Forgery Guide.

Where identity fits

The base URL problem is ultimately a credential problem: the damage depends on what credential the client sends. A long-lived organisation API key on a developer laptop is the worst case. Better options, in order:

Per-user, short-lived gateway tokens obtained through SSO or a credential helper, so a leaked token expires and is attributable.
Workload identity for services (cloud IAM roles for Bedrock or Vertex style endpoints) instead of static keys.
Scoped project keys with spend limits where a provider key must exist. See How to set spend limits on LLM API keys.

If a redirected client may have leaked a key, follow the AI model provider API keys response guide. The LiteLLM MCP auth bypass is a reminder that the gateway you pin to also concentrates keys and must itself be hardened; see the LiteLLM Proxy Security Guide.

Implementation roadmap

Inventory: search repositories, CI variables, container images and developer config for OPENAI_BASE_URL, ANTHROPIC_BASE_URL, base_url=, api_base and tool-specific endpoint settings. List every distinct host found.
Decide the approved destinations: normally one gateway hostname per environment, plus any sanctioned local model servers.
Pin in audit mode first: deploy managed settings and an egress proxy rule that logs, but does not block, connections to non-approved AI hosts for two to four weeks. Review hits with teams.
Enforce: switch the proxy to block and enable tool-level pins such as allowedProviders. Keep a documented exception process with an expiry.
Move credentials: replace shared provider keys on clients with per-user gateway credentials; rotate any key that was ever on a laptop.
Harden project trust: keep AI tools updated, require workspace trust prompts, and add CODEOWNERS review for AI tool config directories.
Rollback: if enforcement breaks a team, re-enable audit mode for that group rather than removing the pin globally, and fix the allowlist.

Detection and measurement

Signal	Where to look	Why it matters
Outbound connections from developer devices or CI to AI-style API paths on non-approved hosts	Secure web gateway, DNS logs, EDR network telemetry	Redirected clients, unsanctioned proxies, shadow AI
Commits adding or changing endpoint variables or AI tool config files	Source control hooks, secret and config scanning	Repository-borne redirection
Gateway credentials used from unexpected networks	Gateway and identity provider logs	A credential captured by a rogue endpoint
Provider usage not passing through the gateway	Provider console usage reports compared with gateway logs	Keys being used outside the pinned path
Server-side requests from the model-integration service to private or metadata addresses	Egress proxy and cloud flow logs	SSRF through a customer-supplied endpoint

Metrics:

Percentage of managed devices with the endpoint pinned by policy.
Number of distinct AI API destinations seen in egress logs per month (should fall to the approved set).
Number of provider API keys held on client devices (target zero).
Percentage of model traffic flowing through the gateway rather than directly to providers.
Time from detecting an unapproved endpoint to remediation.

Common failure patterns

Trusting repository config. Opening a cloned repository applies its tool settings; if those include an endpoint, the clone decides where your key goes.
Gateway as a convenience, not a control. Teams deploy a gateway but leave the provider key on laptops and direct egress open, so any override bypasses it.
Disabling TLS verification for "local" endpoints and leaving it set when the variable later points somewhere remote.
Customer endpoint fields with no SSRF controls, letting a tenant probe internal services from your model-integration workers.
Logging the full request to debug a gateway, which writes authorisation headers and prompts to log storage.

Framework mapping

Framework	Reference	How it applies
OWASP Top 10 for LLM Applications 2025	LLM02 Sensitive Information Disclosure; LLM03 Supply Chain; LLM06 Excessive Agency	Prompts and keys leaving via an untrusted endpoint; untrusted config and third-party endpoints; agents acting on forged responses
OWASP API Security Top 10 2023	API7:2023 Server Side Request Forgery	User-supplied model endpoints
MITRE ATLAS	AML.T0055 Unsecured Credentials; AML.T0034 Cost Harvesting; AML.T0010.001 AI Software	Key theft, spend abuse, compromised AI tooling
MITRE ATT&CK	T1552.001 Credentials In Files; T1195.002 Compromise Software Supply Chain	Keys in config; malicious repositories or packages carrying endpoint changes
NIST SP 800-53 Rev. 5	CM-6 Configuration Settings; SC-7 Boundary Protection; SC-8 Transmission Confidentiality and Integrity; SI-4 System Monitoring	Pinning, egress control, TLS, monitoring
NIST CSF 2.0	PR.PS-01; PR.IR-01	Configuration management; protecting environments from unauthorised use

Practitioner checklist

Inventory every place an LLM endpoint can be set across code, environment, CI, repository config and user config.
Pin the approved gateway in managed or system configuration that project files cannot override.
Block direct egress from managed devices and CI to provider APIs and unknown AI endpoints.
Remove long-lived provider keys from client devices; issue per-user, short-lived gateway credentials.
Keep AI coding tools patched and require workspace trust before project config takes effect.
Require code-owner review for changes to AI tool config directories and endpoint variables.
Apply full SSRF controls to any customer-supplied model endpoint.
Require HTTPS and certificate verification for every non-local endpoint.
Monitor egress for non-approved AI destinations and reconcile provider usage with gateway logs.

Standards and references

Related NHI Mgmt Group resources: AI Gateway and LLM Gateway Guide · Claude Code Security Guide · AI API key abuse · SSRF Prevention Guide

LLM Base URL and Endpoint Override Security Guide: Stop keys and prompts going astray