Darktrace found a LiteLLM gateway on Amazon Bedrock hijacked for cryptomining. What the incident reveals about ai gateway security blind spots and how to harden yours.
Darktrace recently flagged an AWS EC2 instance named "LiteLLM-Proxy." It was running the open-source LiteLLM software, carried an instance profile with access to Amazon Bedrock, and had been turned into a Monero mining rig. The payload was a commodity cryptominer. The interesting part was the target: not a generic VM, but an AI gateway that centralized credentials, model access, and cloud permissions into a single machine.
Most coverage of this incident focuses on the cryptominer. That framing misses the point. The real ai gateway security lesson is structural: gateways fuse cloud identity, AI model access, and operational permissions into one choke point, and nothing in the standard gateway or firewall stack watches what that choke point does at runtime.
The compromised instance had SSH exposed to the entire internet on port 22. Darktrace recorded a heavy volume of short-lived inbound connection attempts from external addresses, consistent with brute-force activity.
Once inside, the attacker pulled 3.42 MB over HTTP from an external endpoint that appeared to host a ZIP archive containing XMRig, a commodity Monero miner. Minutes later, the instance opened connections to a mining pool over HTTPS on port 443, then kept going.
Port 443 is the same port every web server uses. A single encrypted connection to an unfamiliar destination means nothing on its own. What exposed the mining traffic was the destination, the volume of connections, and the absence of anything similar elsewhere in the environment.
One caveat: Darktrace could not confirm SSH as the entry point because host-level logs were unavailable. It also found no evidence linking the incident to publicly disclosed LiteLLM vulnerabilities. The exposure was operational (an open port, likely weak or default credentials), not a software CVE. For a catalog of LiteLLM's disclosed vulnerabilities, see our LiteLLM security vulnerabilities breakdown.
The cryptominer was the loud part. The quieter activity came a day later.
On June 13, Darktrace flagged a different IAM user making a GetSendQuota API call over the AWS CLI from an IP address geolocated in Vietnam. The account had not made that call in at least three months. Working through a long-term access key, the same account generated failed InvokeModel and ListFoundationModels calls (attempted enumeration of Amazon Bedrock), followed by a CreateUser attempt, which Darktrace said may indicate an effort to establish persistence.
Darktrace stopped short of tying the two incidents together. The evidence was not there. But the pattern is worth noting: a compromised gateway instance one day, followed by IAM-level probing the next, using a different identity, from a different geography. Whether connected or coincidental, it illustrates the kind of multi-signal correlation that ai gateway security monitoring needs to handle.
BeyondTrust CISO Sean Malone put the incident in context: strip off the AI branding and this is a cloud intrusion pattern unchanged since at least 2018. SSH open to the internet, brute-force, XMRig, mining pool connections. The AI-specific credential-abuse variant has had a name since 2024: LLMjacking.
The pattern is old. The target is new.
Malone's point about blast radius is the one that matters: AI gateways concentrate credentials, cloud permissions, and model access into a single choke point, so even a routine intrusion lands on a privileged asset. A compromised web server gives you a web server. A compromised AI gateway gives you everything the gateway brokers: API keys, provider credentials, instance profiles, model access, prompt logs.
These gateways are becoming brokers for identity, model access, prompts, logs, and policy. When one is exposed over SSH or backed by broad permissions, it is no longer just another EC2 instance. It is a control point for AI operations.
If you are evaluating gateways and want to compare what is available beyond LiteLLM, we maintain a LiteLLM alternatives comparison.
An AI gateway sits in front of model traffic and manages it. The core jobs are routing (send this prompt to GPT, that one to Claude, fail over when one provider is down), rate and budget limiting, authentication and key management (issue virtual keys so developers do not hold raw provider credentials), and basic guardrails. Products in this space include OpenRouter, Portkey, LiteLLM, and Helicone, with incumbents like Kong and Cloudflare adding gateway features to existing footprints. For a deeper look at what gateways do, see our what is an AI gateway explainer.
The defining limit is scope. An AI gateway only sees what flows through it. Internal agent-to-tool calls, service-to-service hops, resulting API calls, and any AI traffic that does not route through it are invisible. Its guardrails operate on single requests and can be bypassed with basic encoding or obfuscation.
That scope limit is precisely what made the Bedrock incident invisible to gateway-level controls. The cryptominer was not model traffic. It was a process running on the same machine, connecting to an external mining pool. No prompt, no response, no request to inspect. The gateway's own tooling had zero visibility into the attack.
The terminology confusion around AI security tools is not accidental. It results from vendors repositioning existing products (WAFs, API gateways, cloud security suites) with AI-sounding labels as the category formed faster than its vocabulary.
Semantically, the distinction is clean. The gateway governs transport. The AI firewall filters AI inputs and outputs at the model boundary: blocking prompt injection, toxic content, PII, system-prompt extraction attempts. An AI firewall can be shipped as a subset of an AI gateway's functionality, which adds to the commercial confusion.
For the Bedrock incident, neither tool would have helped. The AI firewall reasons about content, not behavior. It can flag a malicious prompt. It cannot tell you that an agent with legitimate database write access just interpreted an ambiguous instruction and dropped a table, because nothing about that request looks like an attack. A cryptominer connecting to a mining pool is not model traffic at all. It lives entirely outside the boundary both tools are designed to inspect.
Both the gateway and the firewall are request-scoped. Each sees a slice of an AI interaction. Neither sees the whole interaction as one connected thing.
| Capability | AI Gateway | AI Firewall |
|---|---|---|
| Scope | Transport layer (routing, rate limits, key management) | Model boundary (prompt/response filtering) |
| Sees | Requests that flow through it | Content at the model edge |
| Blind to | Agent-to-tool hops, service-to-service calls, non-model traffic | Behavioral patterns, multi-step failures, non-model traffic |
| Would catch cryptominer? | No | No |
| Would catch LLMjacking probe? | Possibly (if Bedrock calls routed through it) | No (authorized model calls look normal) |
Darktrace's Managed Threat Detection SOC caught the cryptomining traffic and escalated the alert to the customer, providing timely notification of active resource abuse in the AWS environment. The detection did not come from the gateway stack. It came from correlating workload behavior (unusual outbound connections on port 443) with control-plane signals (IAM activity the next day).
The lesson Darktrace draws: AI infrastructure should not be carved out as its own technology stack. It runs in the cloud, holds cloud credentials, and fails the way cloud assets have always failed. No single alert on that EC2 instance told the whole story. Piecing it together meant watching the workload and the control plane at the same time.
For teams running AI gateways in production, a concrete hardening checklist:
Steps one through four are perimeter hardening. Necessary, well-understood, and insufficient on their own. Step five is the one that changes the detection model: you need visibility into what the gateway does at runtime, not just what passes through it as model traffic.
For teams building on AI gateways, that means treating ai gateway security as a cloud security problem with AI-specific blast radius, not an AI problem with cloud characteristics. The gateway is infrastructure. Secure it like infrastructure. Then add the behavioral layer that infrastructure monitoring alone does not provide.
shim applies tenant controls, PII placeholder processing, and request accounting to supported native provider calls. More detail on the bounded security model is on the security page.
shim provides policy and accounting for supported native provider calls, while host monitoring and incident detection remain responsibilities of your security tooling.