A leaked, non-expiring AWS access key with AdministratorAccess gave an operator a short path to someone else’s AI bill. FortiGuard Labs traced the key through a newly created IAM user, AWS Marketplace agreements for foundation models, and billable model invocations through Amazon Bedrock.
The report covers one compromised AWS account. Fortinet did not name the organization, state the incident’s charges, or quantify other victims of this specific chain. It did show that an attacker can monetize broad cloud authority without first stealing model weights or company data.
One Key Opened Paid Models
The compromise began with a long-lived IAM access key carrying administrator privileges. Fortinet says the operator used it to create another IAM identity and then enabled paid access to foundation models.
That sequence matters because each step uses ordinary AWS control-plane functions. A valid administrator can create users and credentials. An authorized identity can accept a model provider’s Marketplace agreement. Bedrock can then process inference requests and charge them to the account that owns the credentials.
Fortinet describes LLMjacking as theft of hosted model access. The immediate product is inference capacity: the attacker can consume it directly or resell access while the compromised organization pays. The source cites earlier research estimating possible exposure above $46,000 per day for Claude 2.x-class inference and above $100,000 per day for Claude 3 Opus. Those are historical estimates, not losses measured in this incident.
Marketplace Agreements Enabled Billing
Fortinet observed the new IAM user and one or more model subscriptions. In CloudTrail, the Marketplace step appears as CreateAgreementRequest and AcceptAgreementRequest against the legitimate AWS service agreement-marketplace.amazonaws.com. That hostname is shared AWS infrastructure, so its presence needs account, identity, and timing context.
The source says this class of attack may also create Bedrock service-specific credentials through AWS’s long-term API-key mechanism. Those credentials differ from standard IAM access keys. Fortinet did not say that the additional credential step occurred in the investigated account, so defenders should treat it as a related possibility rather than a confirmed event in this case.
Figure details
The top lane shows the observed account activity: a leaked long-lived AWS IAM access key with AdministratorAccess leads to a new IAM user, then paid model access through a Marketplace agreement and Bedrock model calls. The bottom lane shows the defender reconstruction: CloudTrail identity and key-change events lead to CreateAgreementRequest and AcceptAgreementRequest, which defenders correlate with Bedrock invocation logs and charges. The source disclosed one affected account but did not report its charges or a broader victim count.
The final call can resemble legitimate application traffic. Fortinet writes, “It is simply a cloud API used exactly as designed,” even though the credential holder is unauthorized. A first Bedrock invocation therefore establishes usage, not malicious intent.
Logs Reveal the Sequence
CloudTrail is the primary reconstruction record. Fortinet recommends enabling it in every account because it can connect the original administrator identity to the new user, credential issuance, Marketplace operations, and their order. Bedrock invocation logging adds request-level details beyond CloudTrail. That logging is off by default.
Start with unexpected new-identity activity from the exposed principal. Pivot to access-key changes, service-specific credential creation or reset, and CreateAgreementRequest or AcceptAgreementRequest. Then correlate those events with Bedrock model invocations, unfamiliar source IP addresses, enumeration, access-denied noise, and throttling exceptions.
Fortinet cautions that first-time Bedrock use is insufficient on its own. A development team may legitimately adopt a new model. The stronger pattern combines that first use with a newly created identity, an unfamiliar network origin, reconnaissance, permission failures, or an abrupt Marketplace agreement.
Existing Controls Need Activation
Fortinet is evaluating and promoting its own FortiCNAPP product in this research. Its named detections still provide useful search vocabulary for customers and a checklist for teams translating the chain into another cloud-security platform.
The report lists lacework-global-12 for IAM policy changes, lacework-global-13 for IAM access-key changes, and lacework-global-14 for a new AWS user. It names lacework-global-2907 for Bedrock service-specific credentials and lacework-global-2906 for Marketplace agreements. Invocation and audit-evasion coverage includes lacework-global-2038 for Bedrock throttling exceptions and lacework-global-2037 for deletion of Bedrock invocation logging.
Most of those rules are on by default, according to Fortinet. lacework-global-14 is available but requires explicit activation. The Bedrock posture policies lacework-global-1999, lacework-global-2000, lacework-global-2001, lacework-global-2002, and lacework-global-2781 also require enablement or inclusion in a custom framework. Those policies can flag configuration issues such as disabled invocation logging without a CloudTrail integration.
Prevention starts by finding long-lived keys with broad permissions and replacing them with short-lived, assumed-role credentials where workloads allow. Enable CloudTrail across the organization and Bedrock invocation logging before an incident. Alert on new Marketplace agreements and service-specific credential creation in accounts that have no approved AI workload.
Verify Every New Identity
For a suspected key exposure, begin preserving its CloudTrail history and immediately revoke or rotate the leaked credential. Identify every user, role, policy attachment, access key, and service-specific credential the principal created or changed. Review Marketplace agreements and Bedrock calls for the same window, then determine whether each action maps to an approved owner and workload.
Use a concrete verification test: query CloudTrail for identity creation, IAM policy and access-key changes, service-specific credential operations, and CreateAgreementRequest or AcceptAgreementRequest; correlate the results with Bedrock invocation logs. The expected result is a documented owner and business purpose for every new identity, credential, agreement, and model call, with no unexplained activity remaining after containment.
One rotated key cannot prove the account is clean. The defensible boundary is the complete authority chain that key exercised: identities, credentials, subscriptions, and paid inference all need an owner or a remediation record.