Where Leaked API Keys Go

Your leaked API key can become someone else's revenue. The bill still comes to you. An attacker can use a copied key directly or sell access to other people. Buyers receive discounted AI access while the original owner accumulates provider charges.

Following our coverage of the Railway incident, Cremit investigated signs of credential sales. On November 12, 2026, Korean time, we opened two public storefronts, inspected their product descriptions, model pricing and payment instructions, and preserved screenshots. We compared those observations with underground forum advertisements and documented cases of stolen-key abuse.

Public AI-access storefronts are operating openly. Railway estimated about $740,000 in unauthorized use of stolen keys. Credential abuse has also been reported during Cremit's recent incident response work in South Korea.

A provider can restore its platform while copied credentials remain usable elsewhere. Every hour a key stays active gives an attacker more time to spend, relay or resell its access. Teams need to find the copies, check their current status and investigate actual usage.

What Railway's detailed report added

Railway published its detailed incident report on November 10. An attacker obtained an internal credential through a build isolation weakness, reached build histories and internal source code, then used a misconfigured OIDC trust relationship to obtain cloud credentials and access needed to decrypt environment variables.

Railway put the upper bound on potential workspace exposure at 1.85%, approximately 100,000 workspaces. The report described access to 353 build histories, effects on linked tokens for 1,852 users, and an estimated $740,000 in unauthorized use.

The attacker's queries selected environment variable names associated with AI providers. Subsequent unauthorized requests included coding-agent and AI-training workloads. Railway described patterns consistent with access relay or resale.

The technical issue extends beyond encryption at rest. An attacker who can read encrypted values and request their decryption can cross the intended protection boundary. A short-lived cloud credential can also enable longer-lasting harm if its permissions allow the holder to retrieve longer-lived secrets.

An access review therefore needs to examine which workloads can read and decrypt secrets, who can reach those workloads, and what additional credentials those workloads expose. Reviewing each component separately can miss the consequences of their combined permissions.

OpenCode's affected service held customers' provider keys

In its October 17 UTC announcement, OpenCode said the incident affected 1.4% of Console users who had linked external providers. It said it was working with Anthropic, OpenAI and Google. The affected service was the hosted Console where customers connected provider keys.

Bring Your Own Key, or BYOK, lets a team connect an existing provider key to another tool. It separates the tool that holds the key from the issuer that decides whether the key remains usable.

Disconnecting the external tool and revoking the key at its issuer are separate actions. Someone with a copied key may call the provider directly, bypassing the original tool's gateway and usage dashboard. Investigating only the tool's dashboard can miss those requests.

Storefronts we inspected directly

Cremit inspected the product descriptions, pricing and payment instructions on two public storefronts. The pages included model catalogs, developer documentation and balance-recharge steps. The distribution of AI access has the packaging of an ordinary online business.

LLM Routing advertises access at around half the official price

The site at llm-routing[.]com advertised access to OpenAI, Claude and Gemini through one API. Its landing page claimed pricing around half the official rate. A pricing section placed its own official reference prices beside its selling prices. It described usage-based billing, prepaid balances and USDT TRC20 payment instructions.

Xingjiabi lists model prices and supply routes

The site at xingjiabiapi[.]org also had a public homepage and pricing page. At the time of inspection, the pricing page displayed 87 enabled models, input and output rates, and group names containing strings referring to AWS, GCP and OpenRouter.

Infrastructure associated with these two resale operations has also been observed checking stolen enterprise keys. This connects public sales offers with activity involving compromised credentials.

Underground forums also advertise keys themselves

An underground forum account named CyberThreat advertised OpenAI, Anthropic and xAI API keys, starting at $15 with bulk-purchase discounts. The post is dated March 15, 2026.

A VOLTIC advertisement offered access to multiple AI models, pricing tiers and cryptocurrency payment. Its account panel identified DarkForums membership.

A market for credentials and model access existed before the October incidents. Attackers who obtain keys can use established distribution channels.

Hacking forums and Telegram channels bring sellers and buyers together. Public relay storefronts handle pricing, payment and model requests. Through these channels, a company's credentials can become resources serving other people's workloads.

The product can be a key or the access behind it

A buyer can receive the credential itself. Alternatively, an intermediary can keep a pool of credentials and issue its customers separate accounts or access tokens. Those customers can consume the resources behind the original keys without seeing the keys themselves.

Illicit routing layers that pool stolen credentials are known as LLM Mixers. Initial compromise and monetization can be handled by separate actors. Investigated examples include stolen-key use supporting jet-night[.]com and the newapi[.]pro resale ecosystem. Some organizations accumulated charges reaching $1 million before access was revoked.

Defenders need to connect credential collection, resource consumption and attempts to retain access after containment.

Searching for the organization's name may reveal nothing. A relay has little reason to advertise the identity of the original key owner. Absence of a named listing therefore provides little assurance about circulation.

Where to verify actual abuse

A sales advertisement records a seller's claim. A validity result describes a credential at a particular time. A permission policy describes allowed access. Activity records provide evidence of actions already taken. Each answers a different question.

A repository key that remains valid and shows model calls from an unfamiliar source requires urgent response. Record the exposure location and time, contain the key at its issuer and use activity records to trace the impact.

Confirmed unauthorized activity requires immediate response. Issuer-side containment can proceed while investigators trace the distribution path.

Review failed requests as well as successful ones. Unfamiliar models or regions, permission denials, quota checks and later successful calls can provide context. Normal applications and operational tools can produce similar events, so compare them with deployments, authorized work and established traffic patterns.

Check whether model-invocation logging was enabled, whether the relevant period is retained and whether billing records are delayed. Review model usage alongside key-management events to establish the available investigation scope.

Infostealer collections include AI-service sessions and valid API keys. Attackers can use an already authenticated session or a key to continue access without a fresh login. Credential and session exposure therefore belong alongside account-login protection.

Questions raised during response work in South Korea

Credential abuse has also been reported during Cremit's recent incident response work in South Korea. The risk described in overseas platform notices is also a practical response problem for domestic operating environments.

Responders need to determine which credential became known externally, whether it remained valid when used, what its permissions allowed and whether additional access survived containment.

Confirm both deployment of the replacement and revocation of the old key, then review other secrets exposed through the same environment. When a platform announces a breach, compare the credentials entrusted to that platform with their operational dependencies.

This is why a credential protection company needs to address the gap between reading an incident notice and remediating its own organization's keys. Maintaining links between findings, validity, permissions, owners and response records reduces the inventory work that would otherwise begin during the incident.

Before declaring rotation complete

Issuing a key, editing configuration, deploying it and revoking its predecessor are separate states. A response procedure should distinguish them.

1. Identify the credential and issuer. Use issuer key identifiers and access-controlled evidence locations instead of copying secret values into ordinary tickets. Involve the owner when available identifiers are insufficient.
2. Contain current unauthorized use. Disable or revoke an abused key at its issuer under the organization's emergency procedure, accounting for service impact. Investigation should not require leaving an abused key usable.
3. Check replacement deployment. Identify the production, development, batch and CI workloads using the old key. Editing a file and updating a running process are separate events.
4. Confirm the old key's status. Record revocation and the time it was verified alongside replacement issuance. Use authorized accounts and issuer-supported checks.
5. Investigate copies and additional access. Review approved repositories, histories, documents, messages and build artifacts. Include other credentials exposed through the same path and access created during the incident.
6. Record impact and closure evidence. Separate observed activity from gaps in issuer usage, audit and billing records. Track billing refunds separately from credential containment.

Providers differ in their controls. Check whether a budget setting produces an alert or enforces a spending limit, and whether it applies to an organization, project or individual key.

How Cremit connects discovery to response

A credential finding needs to lead to an action its owner can take. The useful question is what evidence the responder receives and where the response continues.

Find copies in code and collaboration tools

Cremit secret scanning inspects connected sources including GitHub, GitLab, Bitbucket, GitHub Packages, AWS S3, Google Drive, Jira, Confluence, Notion and Slack. It supports more than 1,000 credential types. Actual coverage depends on integration permissions and each source's supported scope.

Suppose a newly issued key is pasted into a Slack troubleshooting message and a Jira ticket. Those tools become additional storage locations. A repository-only review can miss both copies. Connected-source scanning follows the work paths through which credentials spread.

External scanning reviews public exposure starting from registered domains or GitHub organizations, with discovery evidence and scope exclusions. It is an Enterprise capability.

Read current validity with its check time

Usable keys need priority. Cremit performs issuer-side validation for supported types and separates findings requiring manual review so teams can set response priorities.

Reverification of supported active keys helps identify state changes. Responders use the method and last-check time to continue issuer activity monitoring and emergency containment.

Use permissions to set investigation priorities

A cloud key restricted to model calls has a different impact from one that can read other secrets or change access. For supported AWS access keys and GCP API keys, Cremit provides permission and restriction context through the required integrations.

Broader permissions call for reviewing more services and credentials. Permission context sets investigation priorities; issuer activity records show how that access was used.

Connect inventory, relationships and ownership

The credential inventory distinguishes scanned findings, synchronized secret-manager entries and manually registered assets by origin. Finding locations and available relationships help responders investigate copies across tools.

Connect finding locations, authors and directory information with the current operational owner. Cremit's relationship context helps teams confirm actual usage and assign the person responsible for remediation.

With those relationships recorded, a platform breach notice leads to a concrete review of related keys, finding locations and owners.

Connect alerts to action and closure

Cremit supports Slack, Webhook, Telegram and Email alerts, incident management, and MTTD/MTTR reporting. Teams can record issuer containment, service recovery and old-key verification within their response process.

SAML/OIDC SSO, SCIM directory synchronization and departed-user credential indicators support access reviews. Employee offboarding should include review and issuer-side retirement of associated machine credentials.

Review secret-manager posture and exposure together

AWS Secrets Manager posture checks help review stored secrets' validity, unused status and duplicate code exposure. Teams can inspect the storage location and copies left in code or documents together.

Review vault inventory and exposure findings within connected inspection scope to identify gaps in secret-manager operations.

Apply access controls to storage and sharing

Cremit Vault stores encrypted secret values by project and environment, with access requests and passkey approval for value access. Existing AWS Secrets Manager, Parameter Store and HashiCorp Vault connections can be synchronized read-only for inventory review. Cremit storage and sharing

For collaboration, teams can share finding locations, assessments and owner information without sharing the value. Where organization policy separately permits direct value sharing, the sender can specify recipients, expiry and a total view allowance, with recipient authentication and revocation. Secret sharing guide

Recipient, expiry and view controls help teams replace persistent chat copies with controlled delivery. Suspected exposure still calls for issuer-side credential revocation.

Rotate supported AWS keys with approval at each stage

Cremit supports rotation of AWS IAM user keys stored in AWS Secrets Manager using a separate write role and approval at each stage. Teams confirm eligible keys, grant the required role and approve the workflow stages. AWS key rotation

Teams still need to connect key creation and secret-store updates with application rollout and old-key retirement. An approver needs to know whether dependent services have switched. Rotation tooling should be integrated with deployment and recovery procedures.

One response, connected functions

When a development platform reports a breach, teams need to identify the AI-provider and cloud credentials entrusted to it and move through the response below.

Cremit connects findings, verification, ownership and response records. Eligible AWS IAM user keys can follow the approval-based rotation flow; owners rotate other keys at their issuers. Record the replacement deployment and old-key revocation together.

What organizations can prepare now

Inventory the credentials entrusted to external services. Connect issuer, consuming service, storage location, current owner and revocation procedure. Include both keys issued directly by model providers and cloud credentials that enable model access.

Reduce potential impact at issuance. Separate services and environments, apply supported permission, network and model restrictions, distinguish spending alerts from enforced limits, and retire unused keys. When adopting short-lived credentials, review renewal authority and permissions to retrieve other secrets too.

Exercise the response process. Check whether issuer-side revocation remains available when the external tool is down, who makes the decision after hours, where replacements must be deployed and how old-key retirement will be verified. Include recovery from service disruption.

The storefronts we inspected had model catalogs, price lists, developer documentation and payment instructions. A copied credential can continue authorizing requests while the team coordinates a response. Every hour it remains usable extends the attacker's opportunity to earn money at the owner's expense.

Cremit finds dispersed credentials, checks their current state and access context, and connects evidence to responsible owners. The goal is to shorten the time between finding an exposed key and closing the access behind it.

See Cremit secret scanning and the credential inventory for supported scope. Connected-source scanning starts with a permanent free plan providing 2 GB per month without a credit card. Enterprise features, including external scanning, are scoped separately.

Investigation date November 12, 2026 KST.