LLMjacking 2026: Seven-Layer Defence Against Bedrock & OpenAI Credential Hijack

Q: What exactly is LLMjacking, and how is it different from prompt injection or data exfiltration?

LLMjacking is the unauthorised hijack of cloud-hosted LLM resources for compute monetisation. Attackers harvest the victim's API credentials (AWS access keys with Bedrock permissions, Azure service-principal secrets with Azure OpenAI access, GCP service-account keys with Vertex AI access, OpenAI and Anthropic direct API tokens) and use those credentials to invoke the upstream provider's model endpoints at the victim's expense. The application itself keeps producing correct output to legitimate customers; the model behaves exactly as designed; the safety filters fire as expected. What changes is the bill, because a parallel population of unauthorised callers is using the same credentials to drive completely different traffic against the same model endpoints, and the cloud provider charges the credential-owner for every token regardless of who issued the request. The framing is structurally different from prompt injection (which manipulates the model's reasoning to produce unwanted output) and data exfiltration (which walks sensitive content out through the response channel) and jailbreaking (which bypasses safety policies to elicit prohibited content). LLMjacking does none of these things — it leaves the model and the application alone. The defensive surface is therefore infrastructure, not the model: the credential lifecycle, the API-gateway enforcement, the network-egress controls, and the spend-velocity tripwires. The application-layer defences for prompt injection and RAG isolation do nothing against LLMjacking because the attacker is not invoking the application; the attacker is invoking the cloud-provider's model API directly with the credentials they harvested, and the cloud provider has no way to know whether the call originated from the application or from an open-source reverse proxy in another datacentre.

Q: What is the ValidationException probe trick, and why is it the LLMjacking-specific signature?

When attackers harvest a stolen AWS key, they need to know whether the credential can invoke Bedrock and which models it can invoke without triggering the AccessDenied audit-log entries that mature security operations alert on. The crude approach — calling bedrock:InvokeModel with a normal payload — leaves AccessDenied entries when the credential lacks permission. The sophisticated approach is to call bedrock:InvokeModel with an intentionally malformed payload — the canonical example is max_tokens_to_sample set to a negative integer for the Anthropic model family on Bedrock. If the credential lacks permission, the response is AccessDenied. If the credential has permission but the payload is invalid, the response is ValidationException. The ValidationException confirms the credential has live permission to invoke the specific model without ever issuing a successful invocation that would consume tokens or trip per-request anomaly detection. The same probing pattern exists for Azure OpenAI (deployment-name enumeration with malformed completion requests, returning Bad Request rather than Forbidden when the deployment exists) and for GCP Vertex AI (model-endpoint enumeration with invalid generation-config parameters, returning InvalidArgument rather than PermissionDenied). The probe is the LLMjacking-specific signature because no legitimate application has any reason to call InvokeModel with an obviously-invalid parameter shape; security operations that are baselined for the application's legitimate API call patterns can detect the probe pattern through the unusual error-response distribution. Detecting the probe is the earliest reliable signal in the attack lifecycle — it precedes the first cent of unauthorised spend by hours or days — and the CNAPP rule that flags ValidationException-heavy callers is one of the highest-leverage detections in the Layer 5 stack.

Q: Why do AWS Budgets, Azure Cost Management alerts, and GCP Billing notifications fail to stop LLMjacking?

The structural failure is that these services default to email or webhook notifications when a spend threshold is crossed. The notification fires; the spend continues. Whether the spend stops depends on whether someone receives the notification, recognises its meaning, has the authority to act, and reaches the right console within minutes — a human chain that is not running over a Friday-to-Monday window. The 2024-2025 incident record shows that organisations with budget alerts configured experienced the same week-end spend explosions as organisations without, because the alerts went to inboxes nobody was reading. AWS does have a more aggressive option — Budgets Actions can attach IAM policies that deny IAM users when a budget breaches — but the actions are scoped to IAM users not roles, they take minutes to propagate, and very few organisations have configured them because they require explicit policy authoring. Azure has Budget alerts with Action Groups that can trigger Logic Apps or Functions, but again the configuration is opt-in and rarely deployed. GCP has Budget pub/sub notifications that can trigger Cloud Functions for automated response, but the latency from threshold breach to cloud-function execution is typically 5-15 minutes, during which the spend continues at full rate. The architectural answer is to move enforcement upstream of the cloud-provider billing surface: hard rate limits at an LLM gateway between the application and the model endpoint, with the gateway dropping requests that exceed the budget rather than alerting on them. The cost ceiling becomes the gateway's token-bucket size times the per-token rate over the rolling window, which is bounded and predictable rather than unbounded and reactive.