AI Gateway Security: Lessons from 2026’s Gateway Vulnerabilities

Your AI gateway knows which models you call, which provider credentials to use, how much you spend, and which policies apply. That makes it the control point for enterprise AI—and a valuable target.

An AI gateway vulnerability is not limited to a flaw in request routing. It can begin in a release pipeline, a credential store, a linked provider account, or a template engine. The common thread is concentration: credentials, configuration, usage, and control meet in one place.

Recent incidents involving LiteLLM, OpenCode Console, Railway, and GitLab AI Gateway show why AI gateway security has to cover that whole system. They also show why deployment location alone is not a security strategy.

Chrysent takes a different approach to the client credential problem. Clients authenticate with governed Chrysent Gateway tokens, not provider keys. The gateway and retained product data stay in your environment, while provider credentials remain outside client applications and become subject to your routing, budget, quota, rate-limit, and spike-protection rules.

What recent AI gateway breaches and vulnerabilities reveal

These incidents have different causes and consequences. They do not prove that open source is insecure, that proprietary software is safe, or that one deployment model is inherently superior. They reveal concrete controls that every gateway buyer should examine.

LiteLLM: release-pipeline compromise

LiteLLM published details of two supply-chain incidents in 2026.

In its March security update, LiteLLM said versions 1.82.7 and 1.82.8 had been published to PyPI and remained live for about 40 minutes. Its investigation identified a compromised Trivy dependency in the CI/CD pipeline, shared CI environments, static publishing credentials, and an unpinned dependency as contributing factors.

In October, LiteLLM reported a separate incident involving version 1.107.0. Its incident report said compromised artifacts were published to PyPI and container registries with credential-stealing malware and remote-code loading tools. The company’s subsequent attack-chain analysis describes an unrevoked master key, stolen GitHub credentials, and unauthorized changes to the release workflow.

The lesson is not that an open-source package is inherently unsafe. It is that gateway security includes the path by which the software is built and distributed. Artifact provenance, scoped release credentials, dependency controls, independent release verification, and tested credential rotation all belong in the evaluation.

OpenCode Console: linked provider credentials

On October 18, OpenCode disclosed a breach that it described as related to a large-scale distillation attack. The company said the incident affected 1.4% of OpenCode Console users and that it had notified those users.

TechCrunch reported that attackers stole some users’ API keys and that developers subsequently reported spending alerts and unauthorized charges. OpenCode’s initial public statement did not establish a root cause or show that every linked provider account was affected.

For affected users, the response was direct: identify linked providers, rotate the associated credentials, and review provider usage for unexpected activity.

For gateway buyers, the lesson is that credential concentration changes the incident’s blast radius. A service that stores or can access provider keys becomes part of your credential boundary. You need to know where those keys reside, how narrowly they are scoped, how quickly they can be rotated, and what evidence is available afterward.

Railway: attackers explicitly targeted AI provider credentials

Railway’s October 21 security disclosure and October 22 preliminary report provide a clear example of attackers targeting AI credentials rather than only infrastructure.

Railway said its early investigation indicated that the attack was attempting to obtain AI provider API keys for distillation attacks. Its forensic analysis identified two higher-risk categories: workspaces containing a large number of environment variables and environments containing a high concentration of AI-provider keys.

Railway recommended that all customers who signed up before October 21 rotate the sensitive variables and keys stored on its platform as a precaution. It also contacted affected customers directly and worked with external providers—including Anthropic, OpenAI, OpenRouter, GitHub, and GitLab—to revoke potentially compromised keys.

AI-provider credentials are valuable because they can authorize expensive inference, enable model-distillation activity, and potentially expose whatever data or provider capabilities the key can reach. Protecting them requires provider-side revocation, credential replacement, and a review of provider usage—not just patching the original host.

GitLab AI Gateway: CVE-2026-90970

GitLab’s official patch advisory describes CVE-2026-90970, rated CVSS 9.9.

Under certain conditions, an authenticated user with Duo Agent Platform access could escape the prompt-template sandbox through a specially crafted flow configuration, leading to arbitrary command execution on the AI Gateway. GitLab remediated the issue in versions 19.2.4, 19.3.2, and 19.4.1.

This incident is particularly important for teams considering self-hosting. The advisory explicitly addresses affected GitLab Self-Hosted AI Gateway installations; GitLab-hosted gateways were already protected.

Self-hosting changes who operates the deployment. It does not remove application vulnerabilities or eliminate the need to patch. Authenticated configuration also remains untrusted input: a valid account should not be able to turn a template or workflow definition into host-level command execution.

The real AI gateway security checklist

The goal is not to find a gateway that claims to be invulnerable. It is to choose an architecture you can govern, inspect, update, and recover.

Start with these questions:

• Where does the software run? Establish where the gateway, control plane, audit records, and retained content reside. Ask which external providers receive request data and who can access that data for support or operations.
• Where do credentials live? Prefer narrowly scoped credentials with a tested rotation process. Check whether plaintext credentials can appear in configuration snapshots, logs, traces, debug captures, or exported evidence.
• Which destinations can the gateway reach? Look for an explicit provider allowlist and controls over scheme, host, port, redirects, and non-provider destinations.
• How is configuration validated? Templates, workflows, and policy configuration should be bounded data, not an unrestricted program running with gateway privileges.
• How are tool calls governed? A policy layer should evaluate proposed calls before the agent harness executes them, returning allow, deny, or human-review decisions without becoming the tool executor itself.
• What evidence is available? Requests, configuration versions, policy decisions, execution outcomes, provider usage, and spending alerts all help during investigation and recovery.
• How are credentials replaced? Test provider revocation and replacement before an incident. Know how many application configurations must change and which limits apply to traffic after replacement.
• How is the release secured? Look for pinned artifacts, verifiable provenance, narrowly scoped release credentials, and a documented update process. Every gateway needs one.

A governed AI gateway inside your environment

Chrysent AI Gateway is a self-hosted control point for model traffic, provider access, spending, policy, and audit evidence. It is available in private beta for organizations that want to evaluate those controls on their own workflows.

Chrysent sells self-hosted software only. The software and retained product data remain in customer-owned or customer-controlled infrastructure. Customer-configured external model providers receive provider-bound request data under the customer’s provider agreement. This supports data-sovereignty and residency requirements without obscuring what actually crosses the provider boundary.

For a broader view of model traffic, spending, interaction policy, and audit evidence, explore Chrysent’s AI governance solutions.

Provider keys stay out of client applications

Client applications authenticate with Chrysent Gateway tokens. They do not need OpenAI, Anthropic, or other provider keys.

Gateway terminates client authentication, evaluates the request against its governance rules, and injects the route-resolved provider credential only after validating the final destination. Provider credentials are never returned to clients.

This reduces the number of places provider credentials need to exist. Instead of distributing them across developer machines, applications, and deployment environments, you give each client a governed Gateway token. Separate tokens for different applications or teams let you narrow permissions and revocation scope.

A leaked Gateway token meets your limits

If a Gateway token leaks, the exposed credential is a Gateway token—not the provider API key used by Gateway to call the model provider.

You can revoke or replace that token centrally without rotating every provider key. Its scope, rate limits, quotas, budgets, and spike protections determine what it can do through Gateway.

With explicit limits configured, a stolen Gateway token does not provide unrestricted Gateway-routed spending. Circuit breakers help stop runaway usage, while budgets and quotas constrain how much damage the token can cause before it is revoked.

This is why governance matters before an incident. Issue narrowly scoped tokens and configure explicit usage limits for each application or team. A broadly shared token with no limits would recreate much of the risk you are trying to avoid.

If a provider key leaks, replace it once

If a provider key itself leaks elsewhere, rotate or revoke it at the provider, then replace it once in the customer-controlled Gateway configuration.

Existing clients continue using their Gateway tokens and the same Gateway endpoint. You do not need to update every application or distribute the replacement provider key.

Provider rotation remains necessary in this scenario. Gateway centralizes the configuration change; it does not revoke the old key at the provider. Likewise, Gateway limits cannot stop an attacker from calling a provider directly with a leaked provider key. The two controls work together: provider-side revocation addresses the exposed key, while Gateway simplifies reconfiguration and governs future traffic.

Adoption without an application rewrite

Clients use the Gateway endpoint through an environment-variable or existing client-configuration change. There is no Gateway sidecar to install and no application rewrite or application-code change required.

That makes it practical to introduce centralized governance without turning the project into a client-migration program.

Content protection with Touchstone

Infrastructure controls do not address every AI risk. Prompts and responses can carry prompt injection, sensitive data, or content your organization prohibits.

Chrysent Touchstone adds prompt-injection detection, sensitive-data redaction, and organization-defined content policy at the prompt and response boundary. Gateway governs model access and usage; Touchstone evaluates the content moving through that interaction.

Together, they give you a more complete governance layer: controlled credentials and destinations, bounded usage, and policy-aware content inspection inside your environment.

Put your AI gateway security model to the test

Start with one real workflow. List the provider credentials, Gateway tokens, model routes, retained logs, agent tools, and usage limits involved. Then ask:

• Which credentials can a client actually access?
• What happens when a Gateway token leaks?
• What happens when a provider key leaks?
• Which limits stop unexpected usage, and where are they enforced?
• What evidence would you have for investigation and recovery?

Chrysent can walk through that workflow with you and assess how its self-hosted architecture fits your governance, security, and data-residency requirements.

AI gateway security should give you control before, during, and after an incident. With Chrysent, provider keys stay out of client applications, Gateway tokens carry your policies, and the software runs in your environment. That is a practical way to reduce exposure—and respond with speed when a credential becomes a target.