Contribution
This post adds original detection content: a credential-to-consumption correlation that treats model invocation as an identity event, not only a cost metric. Unit 42 documents stolen AI API keys feeding transfer stations, while Sysdig traces the same abuse from stolen cloud credentials to a commercial market. The new part here is a cross-plane alert chain that joins key exposure, first-seen invocation context and token consumption before a monthly bill becomes the first incident report.
The pattern
An AI API key has become a resaleable cloud resource. Unit 42 calls the practice token jacking: an attacker steals a developer's key, validates the models it can reach, then routes other customers' prompts through that access. The victim pays the provider while the transfer-station operator sells cheaper access to the same models.
The transfer station matters because it changes the traffic shape. This is not one intruder running a handful of prompts. Unit 42 found proxy platforms that handle credential rotation, model routing and their own billing. The proxy conceals the underlying provider credential from its customers and spreads requests across a pool of stolen keys. Unit 42 says some services can produce tens of millions of API calls per day. Its incident responders also saw exposed credentials added to a transfer station within minutes, with charges reaching nearly a million dollars before containment.
The entry routes are familiar. Information stealers and phishing can compromise a developer account with rights to create keys, provision models or alter spending controls. Long-lived keys also turn up in source repositories, shared file stores, shell histories and build environments. Unit 42 connects the supply to poisoned npm packages that steal credentials as they pass through developer machines and release systems. A token-jacking incident can therefore start as endpoint credential theft, a source-control leak or a cloud identity compromise. The model API is the payoff, not necessarily the first foothold.
Sysdig's research shows that the market predates the latest cases. Its first LLMjacking investigations found actors taking cloud credentials, checking which hosted models were enabled and invoking them through the victim account. Later work found reverse proxies pooling compromised access and an underground marketplace selling the result. By February 2026, Sysdig described model access, inference costs and cloud rights as goods traded through a commercial service rather than a one-off intrusion.
The latest Unit 42 evidence adds an operational detail that changes the defender's deadline. Transfer stations need a steady supply of valid keys, and they can absorb a newly stolen key quickly. Rotation across many credentials also lets the proxy keep serving customers when one victim revokes access. A weekly spend report is too slow for that market.
There is a second consequence. The buyer's prompt may pass through infrastructure controlled by the reseller. Unit 42 warns that developers using these services may receive output from a different model or have their sessions monitored. The victim organisation therefore faces more than an unwanted bill. Its credential may support another party's data processing, prohibited content, offensive research or access from restricted regions, all under the victim's account and policy boundary.
Why it matters to cloud defenders
Hosted model services sit across three organisational owners. Developers hold or request credentials. Cloud platform teams administer identities, network boundaries and model access. Finance watches consumption after it has been converted into cost. Token jacking slips between those views because each team sees a plausible fragment.
A developer may see no sign after a key is copied. The provider receives valid authentication. The cloud audit record shows an authorised principal calling a permitted API. A cost dashboard shows a usage increase, but cost alone cannot tell a product launch from theft. The useful signal appears only when those fragments are joined.
AWS gives defenders two complementary views. Amazon Bedrock records API calls in CloudTrail, including the caller identity, source IP address, user agent, Region and requested modelId for InvokeModel. Bedrock model invocation logging adds the principal ARN, model, input and output token counts, operation and optional request metadata. It is disabled by default, so an account can have CloudTrail evidence without the usage detail needed to measure the abuse.
Azure has a similar split. Native Azure OpenAI telemetry can report service usage, but Microsoft notes that the calling IP has its last octet masked. Microsoft's gateway monitoring design places API Management in front of model deployments so the organisation can retain the full client IP, client identity or application identifier, model and token totals in one log stream. That gateway is not mandatory for every workload, but it becomes valuable when several applications share model deployments and the defender needs to attribute consumption.
The timing also favours the attacker. Model APIs are designed to accept bursts, parallel requests and automated workloads. High consumption is not inherently suspicious. A transfer station can look like a successful batch job unless the defender knows the normal caller, source network, model set, Region and token-rate band for that credential.
Short-lived credentials reduce the damage window, but they do not remove the detection problem. An attacker who compromises a developer account may mint a fresh key, obtain a role session or change a budget alert before invoking a model. The control-plane events around key creation, model enablement and monitoring changes therefore belong beside invocation telemetry. Watching only for leaked static keys catches one entry path and misses the account takeover that creates its own replacement.
ATT&CK mapping
The earliest observable behaviour often maps to T1552.001, Unsecured Credentials: Credentials In Files. A repository, environment file, shell history, shared folder or build workspace can expose an API key without any model call. Secret scanning is useful here, but finding the string does not prove that someone used it. Treat the finding as the start of a timer and search forward for first-seen invocation context.
Where the stolen material is an application access token, the theft maps to T1528, Steal Application Access Token. ATT&CK includes API tokens used by cloud applications and CI/CD systems in this technique. Do not stretch that label across every credential in this market. A static provider key or AWS access key exposed in a file is first T1552.001; a short-lived bearer or application token fits T1528. The detector can normalise both as identity material used for unauthorised API requests, but the ATT&CK mapping should preserve how the credential was acquired.
The payoff maps to T1496, Resource Hijacking. ATT&CK's newer sub-technique T1496.004, Cloud Service Hijacking, is the closest description of a transfer station consuming a victim's paid model service for profit. The parent technique describes the same outcome across hosted and self-managed resources, while T1496.004 gives the cloud-service behaviour a more precise label.
This chain is deliberately narrow: credential exposure in a file, theft of an application token where one is involved, then resource hijacking. Account takeover, package compromise and cloud defence impairment can precede the same outcome, but they are not present in every case. The detector should accept several entry routes while demanding the same payoff evidence: a credential or principal starts consuming model capacity from a context that does not belong to its workload.
Detection guidance
Build the alert around a credential-consumption tuple. For each model invocation, retain the credential or principal, source IP or network, user agent or client identity, model, Region, operation, input tokens, output tokens and request count. Baseline that tuple per workload rather than across the whole organisation. A coding assistant, document summariser and overnight evaluation job can share a provider while having entirely different normal behaviour.
On AWS, start with CloudTrail events where eventSource is bedrock.amazonaws.com and eventName is InvokeModel, InvokeModelWithResponseStream, Converse or ConverseStream. Preserve userIdentity.arn, userIdentity.accessKeyId when present, sourceIPAddress, userAgent, awsRegion and requestParameters.modelId. AWS documents these runtime calls as management events, so the basic identity trail does not depend on enabling a high-volume data-event selector for those four operations.
Then join Bedrock model invocation logs by principal and time. The log schema carries identity.arn, modelId, operation, input.inputTokenCount and output.outputTokenCount. CloudTrail carries userIdentity.arn, userIdentity.accessKeyId when present, sourceIPAddress and requestParameters.modelId. Retain request identifiers in both stores, but do not assume every pipeline preserves a one-to-one request join. Use the principal ARN, Region, model and a measured ingestion-time tolerance as the fallback correlation key, then test that join against known application traffic before alerting on it.
Add a transfer-station hunt above the per-principal baseline. Sysdig found reverse proxies populated with tens or hundreds of keys across several providers. Within one tenant, group invocations by source IP, user agent and Region, then look for unrelated principals converging on the same client fingerprint while spreading across models or running outside their separate workload schedules. This is a hunt lead, not a verdict. Corporate NAT, shared gateways and central batch workers can create the same fan-in, so require a second boundary break such as an exposed credential, an unapproved principal-model pair, logging tampering or abnormal consumption before escalating.
The provider's own CloudWatch Logs Insights example groups usage by identity.arn; extend that grouping by model and a locally measured time window. Alert when a principal crosses both a context boundary and a consumption boundary, for example a first-seen source IP plus a sharp increase in calls or tokens. A rate increase alone is a capacity alert. A new source alone may be a developer travelling. Together they are a security event worth rapid triage.
Use four high-signal context changes:
- A key or principal invokes a model from a source network, ASN, country, user agent or Region not seen for that workload.
- The caller requests a model family it has never used, particularly a higher-cost model or one outside the application's approved list.
- Invocation volume becomes continuous across the workload's normal quiet hours, or the same credential appears from distant networks within an implausible interval.
- Control-plane changes occur shortly before the burst, such as key creation, model enablement, quota changes, budget-alert changes or deletion of model invocation logging.
The last item should raise severity even if spend remains modest. An attacker testing a new key may make only a few calls before placing it into a proxy pool. Sysdig observed attackers calling DeleteModelInvocationLoggingConfiguration before continuing Bedrock abuse, so alert on that event alongside changes to its delivery destination. Disabling logging or weakening a budget notification before a test indicates preparation, not ordinary application growth.
For Azure OpenAI behind API Management, use ApiManagementGatewayLogs as the attribution layer. Microsoft's documented query extracts CallerIpAddress, the response model and prompt, completion and total token fields from BackendResponseBody. Add the authenticated client identity or an application identifier at the gateway, then group by that identity, IP and model. Choose the correlation window from the application's measured request and ingestion pattern rather than imposing one interval on interactive and batch workloads. A shared NAT address is not enough to clear an alert if the client identity, model choice or token rate is new.
Keep prompt content out of the first detector. AWS model invocation logging can store request and response bodies, while an Azure gateway can capture them, but those records may contain customer data or secrets. Identity, network context and token counts are enough to catch most transfer-station behaviour. Restrict prompt review to incident responders and only after the metadata detector fires. This lowers privacy risk and keeps the first-stage query cheap.
False positives will come from load tests, product launches, model migrations, disaster recovery and shared developer gateways. Tune them with declared workload metadata, not blanket exclusions. Record the owning application, approved principals, normal Regions, permitted model families, expected schedules and a maximum token-rate band. Expire launch exceptions. A service principal that was allowed a temporary burst should not retain a permanent exemption from source-network checks.
Absence is also evidence. If a principal produces CloudTrail invocation records but no matching invocation-log records, first check whether logging is disabled in that Region or whether the application used an endpoint the logging feature does not capture. AWS says model invocation logging is disabled by default and covers the bedrock-runtime endpoint, not other endpoints such as bedrock-mantle. Turn that gap into a posture finding rather than pretending missing usage means no usage.
Finally, connect secret scanning to runtime evidence. When a repository or endpoint scanner finds a provider key, hash or fingerprint the credential in the secret-management system without placing the raw value in the SIEM. Search the provider and cloud logs for the corresponding key identifier or principal from the first exposure time onward. A leaked key with no runtime use is a rotation task. A leaked key followed by a new source and model-consumption burst is an incident.
What to do now
Inventory every identity that can call hosted models and every long-lived provider key stored outside a secrets manager. Assign each one an owner, workload, approved model set, expected Region and source boundary. Revoke keys nobody can explain. Replace long-lived credentials with short-lived workload identity where the provider supports it, and prevent developer accounts from changing spending controls unless their role needs that permission.
Enable the telemetry before tuning the alert. On AWS, retain Bedrock CloudTrail events in every active Region and enable model invocation logging to a protected CloudWatch Logs or S3 destination where the data-handling policy permits it. On Azure, enable service diagnostics and put shared model access behind a gateway when several clients need separate attribution. Preserve the client identity, full source IP, model and token totals, but treat captured prompts and responses as sensitive records.
Set model-service budgets and rate controls as containment boundaries, not as the detector. A budget email that arrives after a transfer station has consumed the allowance is an invoice with better formatting. Stream invocation metrics into the security monitoring path, and alert on the combined identity and consumption changes within minutes.
When the correlation fires, disable or rotate the affected key, revoke related sessions, block the unexpected source where practical and preserve the audit window. Check for new keys, model enablement, quota changes, budget changes and logging changes made by the same identity. Then search repositories, developer endpoints, CI logs and shared stores for the original exposure path. Rotating one key without closing that path merely donates its replacement to the same market.
The useful shift is small: model tokens are billing units, but model access tokens are credentials. Defenders need both meanings in the same investigation.