Unlock My Cloud

The AI Gateway Risk: Why Modernising Your Control Plane is Critical for Cloud Velocity

2026-07-15

the-secure-velocity-report The Secure Velocity Report Modernisation, Migration, and the CISSP Edge.

The Secure Velocity Report

Modernisation, Migration, and the CISSP Edge.

Issue #10 | The AI Gateway Risk: Why Modernising Your Control Plane is Critical for Cloud Velocity

đź“° In the News: Critical Proxies and Event-Driven Phishing

Two major security developments this month demonstrate how threat actors are combining massive social engineering campaigns with precision targeting of modern AI infrastructure.

1. Cryptomining Hits Bedrock-Connected AI Gateways

Security researchers at Darktrace reported observing unauthorised cryptomining activity on an AWS EC2 instance named LiteLLM-Proxy, which was actively functioning as a gateway to Amazon Bedrock-hosted AI services. While Monero cryptomining on compromised compute is a familiar post-compromise activity, the true alarm bell here is the asset itself:

"AI gateways sit between enterprise applications and the foundation models those applications rely on. In many environments, they decide which requests are allowed, where those requests are routed, and what activity gets logged... Depending on the deployment, a gateway may hold cloud permissions or model access that would make a compromise more consequential than the abuse of an ordinary workload." — Darktrace

The Secure Velocity Take: Cryptomining was likely just the noisy byproduct of an initial compromise. An AI gateway sits directly in the control plane—routing prompts, managing API tokens, and bridging enterprise apps to foundation models. If an attacker breaches an AI proxy, they aren't just stealing compute; they are standing next to the keys to your enterprise data pipeline.

2. The 500% World Cup Phishing Spike

Simultaneously, threat intelligence from Hoxhunt revealed an unprecedented surge in cyber threats tied to the FIFA World Cup 2026. Between April and June 2026, World Cup-themed phishing attacks spiked by nearly 500%, outstripping prior events like the Paris 2024 Olympics and Eurovision 2026:

"Attacks related to the World Cup built up slowly over several months before the extreme surge in malicious behavior, with quiet early activity detected as far back as February... The World Cup takes place in multiple countries, with dozens of teams participating and over 100 individual games. These factors create a landscape that is primed for bad actors to launch attacks." — Hoxhunt

The Secure Velocity Take: These two stories are deeply connected. Massive, event-driven phishing campaigns act as the "top of the funnel" for attackers harvesting credentials at scale. Once a legitimate user credential is compromised through a lure, the attacker uses that access to seek out high-value, unmonitored assets inside your cloud perimeter—such as an exposed LiteLLM-Proxy sitting on an EC2 instance.

The AI Control Plane: High-Value Targets Disguised as Middleware

To accelerate AI development, engineering teams frequently deploy proxy layers like LiteLLM, LangChain hubs, or custom API routers. These tools provide fantastic operational velocity: they allow teams to swap backend models (switching between Amazon Bedrock, Azure OpenAI, or Google Vertex AI) with a single line of code.

However, in the rush to deploy these gateways, security governance is often overlooked.

An AI gateway is not just another web app. It is a high-privilege control plane. It frequently holds:

  • Long-lived API keys for multiple LLM providers.
  • Broad IAM roles to read and write to cloud storage buckets (S3/GCS).
  • Access to internal vector databases containing sensitive corporate knowledge.

If an engineering team deploys a LiteLLM proxy as a quick-and-dirty EC2 instance without strict security controls, they have effectively created an unmonitored "super-node." When an attacker breaches that instance—even if they initially just run a cryptominer—they have gained a foothold directly adjacent to your AI assets.

Modernising the AI Gateway: Architectural Guardrails

You cannot fix this by banning AI gateways or slowing down your developers. Instead, you must modernise the infrastructure holding these proxies to ensure that a compromised node cannot turn into an enterprise breach.

If you are deploying AI proxies or gateways in your cloud environment, enforce these three architectural standards immediately:

1. Enforce Least Privilege on Proxy IAM Roles

An AI gateway instance should never inherit broad administrative permissions.

  • The Modern Standard: Attach hyper-granular IAM roles to the proxy container using AWS IAM Roles for Service Accounts (IRSA) or EC2 Instance Profiles. Limit the role strictly to bedrock:InvokeModel for specific model Amazon Resource Names (ARNs). Ensure IMDSv2 (Instance Metadata Service Version 2) is enforced with a hop limit of 1 to prevent SSRF (Server-Side Request Forgery) credential theft.

2. Remove Public Accessibility (PrivateLink & Internal ALB)

Why was an AI proxy accessible to the internet in the first place?

  • The Modern Standard: AI gateways should live exclusively within private subnets. Use Application Load Balancers (ALB) restricted to internal VPC traffic or connect applications via AWS PrivateLink / Azure Private Link. Your AI control plane should never have a public IP address.

3. Ephemeral Secrets over Environment Variables

Hardcoding master API keys into container environment variables is a major risk.

  • The Modern Standard: Use managed secret services (like AWS Secrets Manager or HashiCorp Vault) with automatic rotation. Ensure the proxy requests short-lived, temporary credentials on demand rather than storing permanent secrets on disk.

With my CISSP hat on: In cloud security, we often say that "configuration is identity." An AI proxy instance is only as safe as the IAM role attached to it. If you treat AI gateways as disposable, unmonitored utility servers, you are giving attackers a direct route from a simple phishing email to your core foundation models.

The Supply Chain Link: Managing External AI Connectors

The LiteLLM incident highlights an uncomfortable truth: as your organization adopts generative AI, your digital supply chain expands rapidly. You aren't just relying on major hyper-scalers; you are relying on open-source proxies, orchestration frameworks, and third-party SaaS connectors.

If your security team is still evaluating these fast-moving AI tools using static annual questionnaires, you have a critical blind spot. A questionnaire will never tell you if a vendor or internal team deployed an unpatched proxy instance with public internet exposure.

Seeking Beta Partners: Vendor Assure

We built Vendor Assure to bring real-time, continuous visibility to this evolving software and AI supply chain. It eliminates the manual friction of traditional vendor reviews, providing continuous threat profiling across your third-party ecosystem and cloud integrations.

Vendor Assure monitors the dynamic security posture of your third-party tools, APIs, and SaaS platforms, alerting you to credential leaks, misconfigurations, and supply chain exposure before they can be exploited.

We are currently looking for three forward-thinking organisations navigating cloud modernisations to join our Beta programme. If you are ready to eliminate manual vendor risk blind spots and secure your digital supply chain, let’s have a brief, no-pitch conversation.

👉 Join the Vendor Assure Beta Waitlist Here

Next Week: Paid to Fail: Why Relying on Monolithic Pentests Delivers a False Sense of Cloud Security.