LLMjacking and Langflow Flaws: How to Keep Your AI Agents Safe

01LLMjacking is draining millions from cloud bills

Google disclosed that threat actors are commandeering enterprise LLM API keys and using them to launch expensive model calls. The abuse has produced cloud charges that top $1 million for some victims, with daily losses exceeding $100,000 in extreme cases.

The attack chain often starts with a leaked API key—whether from a git commit, a mis‑configured environment variable, or a phishing email. Once the key is in hand, the adversary can issue unlimited requests to any model the key permits, turning the victim’s billing account into a money‑burning faucet.

• Typical entry point: exposed key in source code or CI/CD logs.
• Impact: uncontrolled LLM calls can exhaust budgets in hours.
• Detection: look for spikes in token usage that do not match normal workloads.

02Langflow flaws let unauthenticated code run on agent servers

IBM reported two critical vulnerabilities in Langflow, the open‑source framework many teams use to compose AI agents. The bugs allow a remote party with no account to bypass authentication and execute arbitrary commands on the host machine.

Every Langflow release from 1.0.0 through 1.12.8 contains the defects, and the only remediation is to upgrade to version 1.13.0. Because the flaw lives in the server process, an attacker can inject malicious payloads that the agent subsequently executes, effectively turning the Langflow host into a pivot point.

• No public CVE ID was assigned at the time of reporting.
• The vulnerabilities affect both on‑premise and cloud‑hosted deployments.
• Upgrade immediately; older releases remain exploitable.

03Open‑source AI frameworks are becoming attack surfaces

The two incidents illustrate a broader trend: as AI agents gain access to code execution, secret injection, and external services, the libraries and orchestration tools that bind them together inherit the same risk profile as any software supply chain.

Chinese actors leveraged the ARTEX multi‑agent penetration‑testing framework to automate attacks against more than 200 organisations in 14 countries. The framework’s ability to spin up agents quickly makes it attractive for both defenders and attackers, highlighting the need for strict governance around any tool that can launch code on your behalf.

• Treat AI orchestration layers as high‑value software components.
• Apply the same code‑review and signing processes you use for binaries.

04Practical steps to lock down your agents

Start by isolating every agent in its own sealed microVM. A microVM gives each agent a dedicated kernel and a single workspace directory, so a compromise cannot leap to the host or sibling agents.

Keep API keys off the agent entirely. Use an egress broker that injects the real credential only at the moment the request leaves the sandbox, while the agent sees only a placeholder token.

Enforce a strict allow‑list for outbound connections. Anything not explicitly permitted is refused, eliminating the chance for an agent to call an attacker‑controlled endpoint.

• Enable two‑person approval for any action that touches credentials or external services.
• Record every agent decision in a hash‑chained audit log and verify it daily.
• Take a checkpoint before risky operations; you can rewind in under a second if something goes wrong.

05Building a zero‑trust pipeline with sealed microVMs

When you combine sealed microVMs, an egress broker, and an immutable audit trail, you create a zero‑trust environment for AI agents. The agent never holds secrets, cannot reach the internet except through approved hosts, and any deviation is captured for forensic review.

If you need to test alternative approaches, fork the running machine into live copies—up to eight at once—so you can experiment in parallel without contaminating the original state. Once the winning variant is identified, delete the failed forks and keep the clean checkpoint.