LLMjacking Response Playbook: Contain Stolen AI Keys and Stop the Bill

When an attacker is running your models on a stolen cloud credential or AI provider key, every hour of delay is paid for on your invoice, and the same credential may also reach your prompts, files and fine-tuned models. LLMjacking incidents are usually discovered through a cost spike, an exhausted quota or a provider abuse notice rather than a security alert, so the first responders are often finance or a platform engineer without a procedure. This playbook is a ready-to-adapt procedure for detecting, containing, eradicating and recovering from LLMjacking across cloud-hosted models (such as Amazon Bedrock and Azure AI services), direct model provider APIs and internal AI gateways. It is written for security operations, cloud security and AI platform teams. Background on how AI credentials are stolen and how to prevent it is in the LLMjacking Guide; this page is the response procedure.

How to use this template

• Replace text in square brackets, such as [Organisation], [SOC], [AI platform team] and [Cloud security], with your own names, and complete the contact table in Section 2 before an incident.
• Attach the playbook to your main incident response plan as an annex. It adds LLMjacking-specific steps and does not replace general incident handling. See the Incident Response Plan Template.
• Decision points are marked Decision: with the role that makes the call. Evidence steps are marked Evidence: and should be completed before the containment step that follows, unless the decision owner records why waiting would cost more.
• Provider-specific steps are given for AWS and Azure as worked examples. Add equivalent steps for every other model provider and gateway you use, and keep the provider console links in Section 2.
• Rehearse with a tabletop at least [once a year] and test revocation of a staging key end to end.

1. Scope and triggers

1.1 This playbook applies to any suspected unauthorised use of [Organisation] AI capacity: cloud credentials with model invocation rights, model provider API keys, cloud AI service keys, AI gateway master or virtual keys, and self-hosted inference endpoints.

1.2 Invoke this playbook when any of the following occurs:

• AI spend or token volume exceeds [150%] of the trailing seven-day baseline, or any spend occurs on an account or project with no expected workload.
• A provider abuse, fraud or policy violation notice is received.
• A secret scanner or third party reports an exposed AI key or cloud credential with model permissions.
• CloudTrail shows InvokeModel calls returning ValidationException from a new principal or network, which Sysdig documented as the probe attackers use to test stolen credentials without running a real prompt.
• Calls to GetModelInvocationLoggingConfiguration or DeleteModelInvocationLoggingConfiguration, or changes to logging on any AI service.
• New models enabled, Marketplace subscriptions created, quotas raised or new provider keys, users or projects created outside change control.
• Model usage from source networks outside [approved cloud and office ranges], or a user agent associated with reverse proxies.

1.3 Severity is set at triage and reviewed at each decision point.

2. Roles and contacts

3. Detection and triage

3.1 Evidence: before changing anything, export the following for the period from [30 days] before first suspicious use to now: billing and usage by account, project, model and region; CloudTrail management events for Amazon Bedrock (InvokeModel, InvokeModelWithResponseStream, Converse and ConverseStream are logged as management events by default); Bedrock agent and knowledge base data events if advanced event selectors were configured; model invocation logs if enabled; Azure activity and diagnostic logs; provider admin audit logs; AI gateway request logs.

3.2 Identify the credential: which access key ID, IAM principal, API key, project or gateway virtual key generated the traffic. Record its owner, creation date, last legitimate use and where it is stored.

3.3 Establish reach: list every permission the credential holds, not only AI permissions. A cloud access key used for LLMjacking may also reach storage, secrets or compute, which changes severity.

3.4 Characterise the use: models invoked, regions (including regions you never use), request volume over time, source IPs and user agents, and whether invocation logs show prompts unrelated to your business. Sysdig reported attackers checking credentials against ten AI services, so check every provider the credential could reach, not only the one that alerted.

3.5 Check for defence impairment: logging configuration reads or deletions (ATT&CK Disable or Modify Tools, T1685) and budget or alert changes.

3.6 Decision: [Incident manager] confirms or closes the incident and sets severity. Map the activity for the record: Valid Accounts (AML.T0012), Unsecured Credentials (AML.T0055), Cost Harvesting (AML.T0034) and AI Service Proxies (AML.T0008.005) in MITRE ATLAS; Cloud Accounts (T1078.004) and Cloud Service Hijacking (T1496.004) in ATT&CK.

4. Containment

4.1 Decision: [AI platform owner] with [Application owner] decides whether to revoke immediately or rotate with a short overlap. Default to immediate revocation for Critical and High severity; legitimate workloads can be restored with new credentials.

4.2 Cloud credentials (AWS example):

• Deactivate the exposed access key; do not delete it until the investigation no longer needs it. AWS guidance is to deactivate, confirm applications work with a new key, then delete.
• Confirm the AWSCompromisedKeyQuarantineV2 policy is attached to affected IAM users, or attach an explicit deny for Bedrock and Marketplace actions.
• Revoke active sessions for any role the attacker assumed, and deactivate IAM users you did not create.
• Where an organisation is in use, apply a service control policy denying model invocation in regions and accounts with no approved AI workload.

4.3 Cloud AI service keys (Azure example): regenerate the affected key, and where workloads can move to Microsoft Entra authentication, set disableLocalAuth to true or apply the policy "Azure AI Services resources should have key access disabled". Microsoft states that the shared gateway can keep accepting previously valid keys for a few minutes and up to several hours, so keep monitoring until a request with the old key returns HTTP 401.

4.4 Model provider API keys: revoke the key in the provider console, revoke any other keys created during the suspicious period, and lower project spend and rate limits to the minimum legitimate workloads need.

4.5 AI gateway keys: revoke the virtual or master key, rotate every upstream provider key the gateway holds if the master or admin key was exposed, and remove the gateway from public reachability. The LiteLLM MCP auth bypass showed attackers reading a gateway's master key and harvesting every provider key behind it.

4.6 Self-hosted endpoints: block public access at the network layer and require authentication before restoring service. See the vLLM, Triton and NVIDIA NIM Inference Server Security Guide.

4.7 Set hard spend caps or quotas on affected accounts and projects so that a missed credential cannot keep running up cost while eradication continues.

5. Eradication

5.1 Hunt for persistence created with the stolen access: new access keys, IAM users and roles (Additional Cloud Credentials, T1098.001), new provider keys and projects, enabled models and Marketplace subscriptions, raised quotas, and changed logging or budget settings. Check every region, including those you do not normally use.

5.2 Remove unrecognised resources after preserving evidence, for example snapshots or exports of anything you will need for the investigation.

5.3 Find and close the source of the leak: code or notebook commits, container images, CI logs, client-side applications, IDE plugins, a compromised package or a vulnerable server. The original LLMjacking case Sysdig reported began with cloud credentials taken from a server running a vulnerable Laravel version (CVE-2021-3129), not from a leaked AI key. Use the Leaked Credential Response Playbook to purge the secret from every location.

5.4 If the source was malware or a malicious package on a developer machine or CI runner, treat every secret on that host as compromised and follow the Cloud Access Key Leak Playbook for the remaining cloud keys.

6. Recovery

6.1 Issue replacement access in a better form than the one stolen: IAM roles or managed identities instead of access keys; short-term Bedrock API keys instead of long-term ones; per-application keys held by a gateway instead of shared provider keys.

6.2 Re-enable and protect logging: model invocation logging to a log account the AI principals cannot modify, and alerts on any logging configuration change.

6.3 Restore workloads one at a time, confirming each uses the new credential and that the old one fails.

6.4 Monitor affected accounts at heightened sensitivity for [30 days]: daily spend review, alerts at a lower anomaly threshold, and review of new principals.

6.5 Decision: [Incident manager] closes containment when spend has returned to baseline for [72 hours], all revoked credentials fail, and no persistence remains.

7. Communication and notification

7.1 Internal: notify the CISO, cloud and AI platform owners at triage for High and Critical; notify finance at once for any spend above [threshold].

7.2 Providers: open a support case with each affected provider, report the abuse, ask for usage records by source IP if available, and request review of fraudulent charges. Billing relief is at the provider's discretion; record what was agreed. If AWS notified you of exposed credentials, reply in the AWS Support Center confirming the actions taken.

7.3 Data protection: Decision: [Privacy and legal] decides whether the incident is a personal data breach. Inference-only abuse may not be, but access to stored files, prompts, conversation history, knowledge bases or fine-tuned models trained on personal data may be. For GDPR, a notifiable breach must be reported to the supervisory authority within 72 hours of becoming aware of it. See the AI Incident Reporting Guide.

7.4 Customers and partners: notify where contractual terms require it or where their data or AI capacity was affected.

7.5 Law enforcement: Decision: [Legal] decides on reporting. Microsoft's action against the Storm-2139 network, which resold access using stolen customer credentials, shows providers pursue these groups; your evidence may support such cases.

8. Post-incident review

8.1 Hold a review within [10 working days] covering timeline, time to detect, time to revoke, total cost, data exposure and root cause.

8.2 Record and track actions against these measures:

8.3 Update the AI credential inventory, this playbook and detection rules. The LLMjacking 2024 to 2026 analysis lists the recurring lessons: replace long-lived keys with roles, restrict who can enable and invoke models, keep invocation logging on, set spending alerts and require authentication on every AI endpoint.

Implementation guidance

• Before an incident: build an inventory of AI provider accounts, keys, gateways and cloud AI services with owners and dependent workloads. Without it, Section 4 decisions stall.
• Detection rules to deploy first: spend anomaly per account and project; ValidationException on InvokeModel from new principals; logging configuration changes; model enablement and Marketplace subscription events; usage from unknown networks. See the Denial-of-Wallet and AI Agent Cost Runaway Guide for cost controls that also contain abuse.
• Pre-approve the hard calls: agree in advance that High and Critical incidents revoke first, so responders do not wait for application owners at night.
• Prepare quarantine artefacts: keep tested SCPs, deny policies and gateway kill switches ready to apply.
• Small organisations: a single provider account with hard spend caps, one gateway and this playbook cover most of the risk. Large organisations should automate steps 4.2 to 4.7 with runbooks triggered from the SIEM.
• Framework alignment: NIST SP 800-53 Rev. 5 IR-4 Incident Handling, IR-5 Incident Monitoring, IR-6 Incident Reporting and IR-8 Incident Response Plan; NIST CSF 2.0 DE.AE-02, RS.AN-03, RS.MI-01 and RS.MI-02.

Related NHI Mgmt Group resources: LLMjacking Guide · Leaked Credential Response Playbook · AI Agent Incident Response Playbook · Model Aggregator and LLM Router Key Security · AWS Access Keys Security Guide