How do you detect LLMjacking activity in AWS CloudTrail?

Detect LLMjacking in AWS CloudTrail by looking for unexpected use of model-invocation permissions, unusual principal activity, and spikes in requests that do not match normal application behaviour. Focus on who called the service, from where, and at what volume. Pair CloudTrail review with access policy checks so stolen credentials or abused roles are identified quickly.

What to look for in CloudTrail when LLMjacking is underway

CloudTrail detection starts with a simple baseline question: which principals normally invoke the model service, from which accounts, regions, and IP ranges, and at what rate. Anything outside that pattern matters more than raw volume alone. The useful signals are usually a mix of unexpected caller identity, unfamiliar source context, and a request pattern that does not fit the application’s normal usage profile.

Model-invocation events are most useful when you can tie them back to the specific workload or role that should be using them. If a CI role, admin session, or rarely used service principal begins calling the service, that is a stronger signal than a generic spike. The same is true when calls come from a new region, an unusual VPC path, or a principal that has no obvious business reason to touch the model endpoint.

It also helps to compare CloudTrail activity with what the application should be doing. llmjacking often shows up as bursts of repeated inference calls, odd time-of-day access, or usage that is far above the expected conversational or workflow rate. If the logs show a principal that fits the LLMjacking pattern around abused model credentials, treat that as a prompt to confirm whether the calling identity is legitimate or merely borrowed.

How to separate abuse from normal automation

CloudTrail is strongest when you use it to answer three questions together: who called the service, where the call came from, and whether the volume or sequence of calls matches the workload. A single odd event is often just a misconfiguration or a new deployment. Repeated model calls from the same principal, especially when they are inconsistent with the app’s usual behaviour, are more consistent with credential abuse or an over-permissive role being used outside its intended path.

Look for identity drift as well as request drift. If a role that normally supports one application starts appearing in contexts associated with a different workload, or if the same access path is reused across environments, that can indicate stolen credentials rather than a new feature rollout. This is especially important where the account should only be reached through a controlled AI gateway or a narrow service path. NHIMG’s AWS Security Guide is useful here because it ties CloudTrail to broader AWS logging and identity controls.

Detection improves when CloudTrail is paired with policy review. If the logs show model access from a principal that should not have invocation rights, or if a service role has broader permissions than the application needs, the issue may be a permissions problem before it is an intrusion problem. That means the log review should not stop at event volume, it should also confirm whether the principal could have used the service in the first place.

How to investigate and confirm suspected LLMjacking

Once the activity stands out, investigate the surrounding identity and session context before assuming the model service itself is the problem. Check whether the access key, assumed role, or federated session was expected, whether it was reused in other places, and whether the activity lines up with a deployment, test, or scheduled job. If the same identity is now generating traffic from an unfamiliar host or account path, treat that as a likely compromise path.

CloudTrail should also be used to see whether the attacker is staying inside the model service or expanding outward. If the same principal begins enumerating storage, secrets, or other AWS services after the model calls start, you may be looking at broader compromise rather than isolated model abuse. NHIMG’s AI LLM hijack breach is a useful reference point for how stolen AWS access keys can be used beyond a single model endpoint.

For deeper context, compare CloudTrail with application telemetry, billing, and any gateway logs that sit in front of the model. A sudden increase in request counts, token consumption, or unusual API error patterns can help separate normal retries from abuse. Where the activity appears to come from a stolen role or long-lived key, rotate the credential path and inspect any related sessions or automation that may have inherited the same trust.

Risk and Threat Considerations

LLMjacking is risky because the attacker is not trying to break the model, they are trying to reuse your authenticated access to it. That can drive up cost quickly, exhaust quotas, expose downstream data, or let an outside party operate under a legitimate AWS identity until the behaviour is noticed.

Failure mechanism: A leaked key, abused role, or overly broad permission set allows an attacker to invoke model services through normal CloudTrail-visible APIs, often in a pattern that looks like real automation until volume, source, or principal context is checked.

Impact: You can get runaway spend, service disruption, and a delayed incident because the access path appears valid in logs unless identity, source, and usage pattern are analysed together.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1078 — Valid Accounts	LLMjacking commonly uses stolen or abused AWS identities to invoke services.
Recommendation — Hunt for unexpected use of valid AWS credentials and correlate them with model-invocation events.
CIS Controls v8	CIS-6 — Access Control Management	CloudTrail detection must be paired with rights review to spot abused roles and excess access.
Recommendation — Review and revoke overbroad access paths for principals that should not invoke model services.
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	Stolen keys are a common LLMjacking entry path, and CloudTrail helps reveal their use.
Recommendation — Investigate leaked or reused credentials when CloudTrail shows abnormal model access.
NIST SP 800-53 Rev 5	AU-6 — Audit Review, Analysis, and Reporting	CloudTrail is an audit source, and this control supports analysing anomalous service use.
	IA-5 — Authenticator Management	Abused keys, tokens, and role sessions are central to LLMjacking detection and response.
Recommendation — Correlate audit records with identity context to identify anomalous model invocation. Rotate and invalidate compromised authenticators when CloudTrail shows suspicious invocation patterns.

Practitioner Guidance

What to verify: Confirm which principals are allowed to invoke the model, and whether CloudTrail shows only those principals using it. If a role can call the service but the application never should, treat that as excess exposure even before you see abuse.

What to measure: Track baseline invocation rate by principal, account, region, and source network so that spikes and unusual call paths stand out quickly. The most useful alert is not “high volume” alone, but “high volume from a caller that should not normally be there.”

Practitioner takeaway: Effective detection depends on correlating identity, source, and consumption pattern, because LLMjacking in CloudTrail often looks legitimate until you compare the caller against the application’s expected behaviour.