Cloud-security teams investigating stolen model access should establish who could enable new AI services and create additional identities, then trace what those identities did. Rotating the first exposed key can leave other access paths and newly activated services unresolved.
That is the operational lesson Maetra draws from Mandiant and Google Threat Intelligence Group's November 2 LLMJacking report. Mandiant describes incidents in which attackers hijacked enterprise model resources. It reports fraudulent resource charges exceeding $100,000 in a single day in individual incidents and cumulative charges reaching $1 million at some organizations. These are attributed observations from investigated cases, not an average loss, an industry-wide rate or independently audited financial results.
Investigate the ability to switch services on
The report says exposed or stolen cloud identity tokens were the dominant initial access route across multiple investigations. It also describes cases where LLM services were not enabled when the compromise began. Attackers used their access to enable services and consume resources. The practical implication is that an inventory of currently used models does not describe every model service an identity could activate.
Start the investigation with the affected cloud project, subscription or account and the identity's permissions at the relevant time. Compare the services that were enabled before the suspected intrusion with subsequent changes. Identify the actor, timestamp and configuration for each unexplained activation.
This review should include ordinary automation identities. A deployment service account may need to provision approved infrastructure while having no business reason to enable an additional model provider. Determine whether those powers can be separated in the actual environment. Do not assume that a credential's familiar name makes its use legitimate.
Build an access lineage, not just a key list
Maetra recommends recording the relationship between the initial identity and any access created during the incident. Capture new accounts, credentials, grants, sessions and services, together with their owners and current state. Where records are incomplete, mark the relationship as uncertain instead of joining events solely because their timestamps are close.
A useful investigation record answers four questions:
- Which identity first obtained access, and what evidence supports that conclusion?
- What new authority or credential did it create or obtain?
- Which resource did that authority reach, and what requests were accepted?
- What evidence shows that the access path has been closed?
The last question changes remediation. Revoking a parent credential may have different effects on derived sessions or independently created accounts. Have the relevant identity owner verify those effects. Preserve the evidence needed for investigation before removing confirmed malicious artifacts, following the incident team's procedures.
Correlate small probes with configuration changes
Large usage spikes are useful signals, but waiting for a large bill makes financial impact part of detection. The report describes low-volume validation of stolen keys as well as high-volume abuse. That supports examining access patterns alongside configuration changes and identity events.
For a bounded review, select one model service and compare a period of normal activity with the suspected exposure window. Look for first use by an unexpected identity, an unusual service activation, a new credential or a change to logging. Investigate combinations of signals in context; a single unfamiliar request is not proof of compromise.
Assign a cloud-security owner and a cost owner to the same timeline. Security telemetry may establish which requests succeeded, while billing records describe attributed consumption over a different reporting interval. Keep those distinctions visible when estimating impact. Avoid presenting a preliminary usage estimate as a settled invoice or confirmed loss.
Verify containment with the resource owner
The report provides cloud-specific detection and remediation guidance. The response team should apply the relevant provider controls and verify their behavior in its own environment. Budget notifications, usage quotas, credential restrictions and service-enablement permissions have different purposes and enforcement semantics.
For example, a budget notification may inform an owner while requests continue. A configured quota may constrain one resource without covering every region, model or identity. Determine the actual scope before treating either as a containment boundary. These are review questions, not claims that every provider behaves the same way.
After remediation, verify the intended state: unauthorized identities are disabled, unexplained grants are removed, unnecessary services are restricted and the required logs remain available. Test approved application access as well, so recovery does not silently break the legitimate workflow.
Keep the source claims and product role precise
The Register independently covered the report, including comment from Google's threat-intelligence leadership. That corroborates the disclosure and attribution. It does not independently reproduce the incident investigations or verify each victim's costs.
An evidence-backed agent inventory provides a useful starting point for identifying the applications and owners involved. Extend the incident review to identities and services outside that inventory.
Maetra Secure scans prompts, messages, tool calls and outputs for runtime threats, including data exposure. Such inspection can contribute evidence about covered application activity. Cloud IAM, credential revocation, service restrictions and financial controls still require enforcement by their respective systems. This article does not claim Maetra prevented or detected the reported incidents.
Use Maetra's documentation to identify the application events relevant to one incident timeline, then connect those records to the cloud identity and resource evidence. The review is complete only when the responsible owners can explain both the legitimate workflow and the remaining uncertainty.