After this week's breaches, where should your API keys live?

Security roundup·23 October 2026

An API key can travel a long way before it makes a request. A developer pastes it into a hosting dashboard, adds it to an AI console, and saves another copy in an integration. Each copy gives another system a way to act on the account that issued it.

The October disclosures involving Railway, OpenCode, APITemplate, and LiteLLM make that inventory urgent. They involve different products and failure modes. Together, they raise a useful question: which systems need the raw key, and which only need permission to perform a specific operation?

Reviewed October 23, 2026. This is a focused roundup of credential-related disclosures from October 17–21, including activity that began earlier. It is not a complete list of the week's security incidents or evidence of a common attacker. Seekrit publishes this analysis and builds credential-management tools.

What was disclosed?

Railway recommended rotating stored credentials and reviewing service logs. Its status record reported builds available across all plans on October 22 at 22:49 UTC; an October 23 update noted new build queuing unrelated to the security disclosure. Treat recovery status and credential remediation as separate work.

OpenCode's announcement described the activity as related to a distillation attack. That description does not explain how access was obtained. The company statement is also reproduced in this report.

APITemplate dated the unauthorized activity to October 12–16. Its notice specifically tells customers to revoke affected storage credentials at their issuer and review storage logs from October 12 onward.

For LiteLLM, the vendor lists affected PyPI wheels between 11:39 and 13:23 UTC on October 21, and affected container tags including latest, main-latest, and main-stable. A later clean tag does not prove an earlier deployment was clean. Follow the report's recovery guidance; simply downgrading is not a complete response to a compromised host.

Our longer reports cover Railway, OpenCode, and APITemplate.

Map what a compromised system could reach

The following is our architectural analysis, not a reconstruction of the four attacks.

Start with one production credential. List every place that holds it, can decrypt it, or can ask another service to use it. Include CI runners, debug logs, inactive integrations, developer machines, and deployed processes. For each location, record an owner and a revocation path.

Three questions reveal different risks:

• Who can read it? A database reader, a host administrator, or code running inside an authorized process may have different routes to the value.
• Who can use it? A caller can have permission to invoke an API without receiving the reusable credential. That permission still needs limits.
• Who can change those permissions? A separate broker offers little isolation if the application can redeploy it or rewrite its policy.

Encryption protects stored values when decryption authority remains secure. A secrets manager can improve distribution and rotation. Neither fact, by itself, hides plaintext from the process authorized to receive it. If a compromised workload can fetch and decrypt every production key, moving the keys to another database has not removed that workload's access.

Give the application only the authority it needs

For supported HTTP integrations, one option is to keep the upstream key in a separately controlled credential broker. The application supplies a placeholder and authenticates to the broker. The broker checks the request, inserts the credential, and forwards only permitted operations.

The separation must include the broker's host, deployment credentials, and administration. A sidecar on a host controlled by the attacker does not provide that protection. Keep the real key and any token capable of decrypting it outside the application environment.

This changes what an application compromise can expose. It does not make the application harmless: stolen broker access can still authorize permitted requests, incur costs, or expose data. Authenticate callers, restrict destinations and operations, and apply usage limits. The broker remains a trusted component, and the receiving API still sees the credential it needs to authenticate.

Some workflows need a different split. A document renderer can return its output to a worker you control, which performs the storage upload. That keeps the storage credential away from the renderer, although the renderer still sees the document. Short-lived credentials, narrow permissions, and separate keys per integration can further limit exposure where supported.

What to do with this inventory

1. Identify affected systems before replacing credentials. Follow each vendor's exposure criteria. For a compromised host, contain it and follow recovery guidance before giving it replacement secrets.
2. Revoke exposed credentials at the issuer from a clean environment. Deleting a dashboard value does not invalidate a stolen copy. Plan for service interruption when immediate revocation is necessary.
3. Review what those credentials could authorize. Check upstream usage, access logs, billing, and permission changes. Preserve relevant evidence.
4. Reduce the next credential's reach. Use distinct integration identities, the minimum permissions required, and short lifetimes where available.
5. Test the replacement path. Verify that services use the new credential, the old one fails, and a future rotation has a named owner and a working procedure.

Where Seekrit fits

Seekrit's credential broker can substitute placeholders on permitted HTTP requests while the upstream key lives outside the application. It needs the separation described above. Storing a decrypt-capable SEEKRIT_TOKEN beside the application, or syncing plaintext keys into the same hosting platform, does not achieve it. Protecting the broker and limiting the caller's authority remain part of the design.

We cannot claim this would have prevented these intrusions. The specific goal is to remove a reusable upstream credential from systems that only need limited permission to request work.

Start with one integration: use our deployment walkthrough to map the application, broker, and provider, then decide which credentials and administrative permissions must move to make the separation real.