In several recent incidents we investigated at KPMG, we observed attempts to access Amazon Bedrock in the earliest stages of the intrusion, and then repeatedly afterwards. On its own, this observation does not demonstrate that the attackers succeeded in using the models, or that they all pursued the same objective. It does, however, justify examining what Bedrock access is worth to an attacker and comparing those attempts with abuse already documented publicly.
Model access is now a resource that attackers can consume or resell at the expense of the compromised organization. This abuse, generally called LLMjacking, has been documented on Bedrock since 2024. It must be distinguished from a vulnerability in the AWS platform: the cases examined rest mainly on compromised credentials and the permissions attached to them.[13][17]
What an attacker could actually do with Bedrock access
Bedrock provides managed access to foundation models. An attacker holding the necessary inference permissions can therefore obtain responses without hosting those models or paying for the requests from their own account. They can use this capability directly or integrate it into an application that serves other users. Depending on the models reachable, that capability can serve to produce and translate text, help write code or analyze documents. Using it to prepare fraudulent messages or to assist offensive operations is a plausible scenario, but it should not be presented as the demonstrated objective of every unauthorized access.[1][15]
Bedrock’s catalog of open-weight models is not limited to OpenAI. AWS offers, among others, the GLM models from Z.ai (Zhipu AI), including GLM 4.7, GLM 5 and GLM 5.3. The latter has been available since October 5, 2026 to eligible enterprise customers, through cross-region inference profiles; its presence in the catalog therefore does not mean it is reachable by any compromised identity.[27][28]
These capabilities can indeed serve offensive operations. AWS itself documents the use of GLM 5.3 on Bedrock with Strix, a penetration testing agent that looks for vulnerabilities and attempts to validate them with proofs of concept, in an explicitly authorized setting.[29] An attacker could divert that capability to assist vulnerability research and exploitation against unauthorized targets. This is a scenario of misusing a documented capability, not a GLM incident on Bedrock demonstrated by that source. Interactions with the targets would be carried out by the tools connected to the agent, in the operator’s environment; a Bedrock inference call alone does not execute an attack against a third-party system.
One cannot, therefore, infer from the protections described by OpenAI that every model in the catalog would resist malicious use in the same way. Conversely, neither open weights nor the provider’s origin demonstrates that a model accepts any request “without restrictions.” A plain inference permission does not allow the weights of the served model to be modified either; customizing a copy is a separate scenario.[26] For the organization, protection must rest on IAM/SCP permissions and on guardrails actually enforced on the compatible paths, rather than on the model’s presumed refusals alone.[2][5] AWS policies prohibit unauthorized use, but that prohibition does not by itself constitute a technical block on every offensive request.[12][29]
The most immediate benefit does not even require the model to produce prohibited content. A coding service or a chatbot can generate ordinary responses while consuming stolen inference capacity. The harm to the victim then lies in the billing, the quota consumption and the persistence of illegitimate access. Conversely, obtaining the right to invoke a model does not automatically grant access to internal documents, to the provider’s training data or to the whole AWS account. Access to a knowledge base, or the execution of actions by an agent, depends on other permissions and integrations, which must be assessed separately.[4][17]
Restrictions exist, but they do not all address the same problem. AWS enforces a responsible use policy and allows a guardrail to be required for certain inference APIs. These mechanisms complement access control; they do not replace verifying the identity and the right to consume the resource. A content filter cannot, on its own, prevent a stolen credential from funding an application whose requests look acceptable.[5][12]
The current configuration also warrants revisiting assumptions inherited from early deployments. Since the simplification announced in October 2025, the absence of manual model activation is no longer a protection to rely on in commercial regions. AWS states that control must rest on IAM and SCPs, which in our experience is rarely implemented correctly by customers. Prerequisites still vary by model and by account, and denying only Marketplace subscriptions is not enough to block every invocation. The former PutFoundationModelEntitlement permission, present in historical reports, no longer has any effect.[2][3] Mandiant also observes that, in several 2026 incidents, model services were not enabled at the time of the compromise: it was the stolen credentials that made it possible to enable them, with Bedrock cited among those services.[24]
What public incidents already establish
Not all of the early publications demonstrated successful consumption. In May 2024, Sysdig notably describes deliberately invalid InvokeModel calls intended to test the capabilities of stolen credentials. A validation error was an indicator of reconnaissance, not proof that a response had been generated. In September 2024, however, the team published observations of prompts and responses obtained through Bedrock, along with model activation attempts and actions targeting detailed logging.[13][14]
Permiso contributes an element particularly close to our initial observation. In its report of October 3, 2024, the team distinguishes customer incidents from a honeypot experiment: after a decoy key was published on GitHub, the first Bedrock attempts arrived within minutes. In that same research environment, it then observed more than 75,000 successful invocations in two days, used to power a role-play chat service, notably with sexual and violent content. Those measurements come from the honeypot, not from a customer bill. They nevertheless demonstrate effective use of the diverted capability, beyond the mere discovery of the service.[17]
The 2026 observations also show that this verification is built into secret-harvesting tooling. Datadog describes sequences of identity validation, model enumeration and then inference tests, as well as scripts dedicated to determining a key’s value for Bedrock. Its researchers explicitly distinguish tool analysis from events observed at their customers: an interface displaying a Bedrock capability does not by itself prove that the capability was exploited.[19][20]
The financial consequences are no longer a matter of projections alone. DoiT reports roughly 1.4 million dollars in unauthorized charges across its support cases from June to October 2026, including one case of 522,000 dollars. These are amounts reported by that responder, without publication of the total number of cases or of final billing adjustments. On October 30, 2026, Wiz also describes two downstream cases of compromised keys, with about 800,000 Bedrock calls in thirty hours for the first and 1.7 million in thirteen hours for the second; the source distinguishes successful calls from denials and throttling. In both cases, an initial validation of the keys occurred within thirty minutes of the secrets being accessed at the compromised provider.[21][23]
The report published on November 2, 2026 by the Google Threat Intelligence Group and Mandiant confirms that this trend extends beyond one provider, one region or one sector. The team describes several 2026 engagements in North America, South America and Asia-Pacific, with fraudulent charges exceeding 100,000 dollars in a single day and a cumulative total reaching one million dollars before access was revoked. Above all, it documents a specialization of the market: initial access actors pass already validated keys to the operators of “LLM Mixers,” illicit gateways that aggregate stolen credentials, meter consumption and resell model access to subscribers. These observations span several cloud platforms and several model providers; the published amounts and indicators are not broken down by service and must therefore not be attributed in full to Bedrock.[24]
The conclusion is clear: Bedrock inference abuse is an operational risk that is already real, with successful use, automation and documented commercialization. The sources do not allow its global prevalence to be measured. They also show that protections can work: in the JINX-2401 case detailed by Wiz, SCPs blocked the invocations despite the administrator privileges of the compromised identity and the attacker’s repeated attempts.[15][18][23][24]
Reducing the risk with a tailored LZA and operational detection
To protect yourself, it is advisable to start with identities and effective permissions: replace long-lived keys with federated identities or time-limited roles wherever possible, restrict the models and inference profiles that can be reached, and deny Bedrock in accounts that do not need it. Temporary credentials remain exploitable too if they are stolen; shortening their lifetime does not remove the need to limit their permissions and their usage contexts.[2][19]
A properly governed AWS landing zone, in particular with the Landing Zone Accelerator on AWS, provides a basis for deploying these controls consistently and centralizing logs. Its value depends, however, on the configuration chosen. It must include SCPs adapted to Bedrock, protect the security accounts, keep exceptions under control and verify cross-region inference paths. Installing the LZA means neither that these decisions have been made nor that abuse scenarios are automatically blocked.[9][10][23]
A CNAPP should complement this architecture by correlating secret exposure, effective permissions and observed behavior. A posture feature alone is not enough: check for operational detection covering Bedrock, identity creation, Marketplace agreement changes and logging changes. The summary published by the Cloud Security Alliance insists precisely on combining posture, entitlement management and runtime detection, rather than on an isolated control.[11]
This monitoring must cover the right logs. Standard InvokeModel and Converse calls on bedrock-runtime are recorded as CloudTrail management events. Prompts and responses fall under separate logging, disabled by default, which requires privacy and retention decisions. Other paths, including agents, knowledge bases and inference on bedrock-mantle, require explicitly enabled data events. A generic “CloudTrail is enabled” collection therefore does not guarantee coverage of every use.[6][7][8] Expected volume should not serve as the only alerting criterion either: Mandiant describes deliberately quiet validation sweeps, limited to a single-token request, intended to confirm a key’s viability without triggering detections based on volume anomalies.[24]
Finally, cost alerts, including on Marketplace products, should complement activity signals without serving as the only protection. It is advisable to test, in an authorized environment, that a compromised identity cannot invoke models outside its scope, that its attempts raise an alert and that containment also revokes persistent access. It is this end-to-end verification, combining the LZA with the actual capabilities of the CNAPP and the SOC, that reduces the time between the first Bedrock test and the end of the abuse.[18][21]
Sources
- [1] AWS — What is Amazon Bedrock
- [2] AWS — Simplified Amazon Bedrock model access
- [3] AWS — Model access
- [4] AWS — Agents permissions
- [5] AWS — Enforce guardrails
- [6] AWS — CloudTrail and bedrock-runtime
- [7] AWS — Model invocation logging
- [8] AWS — CloudTrail and bedrock-mantle
- [9] AWS — Landing Zone Accelerator overview
- [10] AWS — LZA centralized logging
- [11] CSA / Tenable — Securing AI workloads in AWS
- [12] AWS — Responsible AI Policy
- [13] Sysdig — LLMjacking: stolen cloud credentials used in new AI attack
- [14] Sysdig — The growing dangers of LLMjacking
- [15] Sysdig — LLMjacking targets DeepSeek
- [17] Permiso — Exploiting hosted models
- [18] Wiz — JINX-2401: LLM hijacking on AWS
- [19] Datadog Security Labs — Attacker infrastructure, but vibe coded
- [20] Datadog Security Labs — How exposed AWS keys are tested for Amazon Bedrock access
- [21] DoiT — LLMjacking: when attackers run Claude on your AWS bill
- [23] Wiz — Black October for AI developer platforms
- [24] GTIG / Mandiant — The rise of LLMjacking
- [26] OpenAI — Introducing gpt-oss
- [27] AWS — Z.AI models in Amazon Bedrock
- [28] AWS — GLM 5.3 availability
- [29] AWS — GLM 5.3 on Amazon Bedrock and authorized penetration testing
