Why AI Gateway Security Is Now a First-Class Perimeter
AI gateway security is the practice of protecting the components that broker traffic between enterprise data, tools, and machine learning models, including gateways, SDKs, agents, and model-serving infrastructure, using the same identity, access, monitoring, and patching controls that protect traditional application perimeters. CISA’s decision to add a LiteLLM command injection bug to its Known Exploited Vulnerabilities catalog signals a shift: attackers now treat AI plumbing as prime real estate. These systems sit between models and high-value data stores, with broad, often undocumented access. At the same time, flaws in tools like the Google Vertex AI SDK show that model deployment paths can be abused for code execution inside managed serving environments. Together, these issues mark AI infrastructure as an attack surface in its own right. Security teams that still see gateways and SDKs as low-risk middleware are giving intruders a shortcut into sensitive systems and data.
The LiteLLM Vulnerability: When the Gateway Becomes the Breach
The LiteLLM vulnerability chain shows how a single AI gateway can expose everything it can reach. The core bug, CVE-2026-42271, is a command injection flaw in two Model Context Protocol test endpoints that pass unsanitized input into system-level operations. On its own, it requires credentials. Paired with CVE-2026-48710, an authentication bypass involving forged host headers, it turns into unauthenticated remote code execution for anyone who can access the gateway. CISA noted “sustained targeting of AI gateway infrastructure,” and this is the second LiteLLM flaw seen in active attacks within a month. LiteLLM deployments can expose more than 200 data connectors, from document stores to code repositories and financial warehouses. When the gateway falls, attackers do not need separate credentials for each downstream system; the gateway already holds them. The blast radius now matches the full set of data and services wired into that AI fabric, rather than the gateway alone.
Service Account Governance for AI Agents and MCP Endpoints
The LiteLLM incident is less about exotic exploitation and more about poor identity hygiene. AI agents using MCP endpoints behave like classic service accounts: automated identities with broad, persistent access that can trigger real business actions. Yet they are rarely governed as such. Many organizations grant agents the permissions of whoever provisioned them, with no scoping, rotation, or clear owner. According to analysis cited by CISA’s advisory, “AI agents querying enterprise data through MCP endpoints are, from a security architecture standpoint, service accounts.” That means the usual discipline must apply: minimum necessary permissions scoped to each agent’s specific function, documented ownership, short-lived credentials, and predictable rotation schedules. Test endpoints should be disabled or tightly restricted in production. Logs must clearly record which agent used which connector, for which data, at what time. Without this, AI gateways become opaque super-users whose actions and compromises are almost impossible to investigate.
Vertex AI SDK Flaw: Bucket Squatting and Model Hijacking
The Vertex AI SDK flaw shows that AI gateway security also extends to client tools and model pipelines. Unit 42 found that the Python SDK could pick a predictable temporary Cloud Storage bucket name for uploads, derived from the project ID and region. If a developer left the staging_bucket parameter unset and the bucket did not already exist, an attacker could pre-create that bucket in their own project. This “bucket squatting” meant the victim’s model files were uploaded into the attacker’s bucket, where they could be swapped for a malicious model. Many Python models use pickle or joblib, which can run code when loaded. When Vertex AI loaded the tampered model, attacker code executed inside the serving container. In Unit 42’s test, the payload stole an OAuth token from the metadata server that could reach other model artifacts and certain metadata services in the same Google-managed tenant. Updating to SDK version 1.148.0 or later is essential.
From 3‑Day Patching to Continuous AI Infrastructure Hardening
CISA’s three-day patching mandate for Known Exploited Vulnerabilities underscores how quickly AI-facing flaws can be weaponized. LiteLLM’s inclusion, with a 13-day remediation window for federal civilian agencies, should push enterprises to treat AI components like internet-facing apps: always inventoried, monitored, and ready for emergency change. AI infrastructure hardening now means more than firewall rules. Security teams should implement scoped access controls on all MCP and SDK integrations, disable unused or test endpoints, and require authentication and network segmentation for what remains. Centralized audit trails must cover agent actions, data connectors, and model deployments end to end. Credentials and tokens associated with gateways, agents, and serving workloads need short lifetimes and automated rotation. Finally, treat AI gateways, SDKs, and model-serving systems as first-class members of your vulnerability management program, with the same rigor applied to web APIs and identity providers. The attack surface has moved; your controls have to follow.
