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

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?

| Incident | What the published account establishes | What to check |
| --- | --- | --- |
| **Railway · October 21** | Possible access to customer environment variables, including some decrypted contents. | Credentials stored in platform variables, their permissions, and upstream usage. [Vendor disclosure](https://blog.railway.com/p/security-disclosure-wednesday-october-21st). |
| **OpenCode Console · October 17** | OpenCode said the breach affected 1.4% of Console users, a subset with external providers linked. | Affected provider keys and account activity. This scope does not establish compromise of every local OpenCode installation. [Company announcement](https://x.com/opencode/status/2111519637049319818). |
| **APITemplate · October 19** | Template execution enabled access to stored upload credentials and some API logs. | S3, R2, other S3-compatible, and Azure credentials in post actions, including inactive ones. [Vendor notice](https://apitemplate.io/incidents/2026-oct-incident/). |
| **LiteLLM · October 21** | A compromised release pipeline distributed credential-stealing malware in version 1.107.0 through PyPI and container registries. | Installed artifacts, image digests, and credentials reachable from affected hosts. [Vendor report](https://docs.litellm.ai/blog/security-incident-oct-21-2026). |

Railway recommended rotating stored credentials and reviewing service logs.
Its [status record](https://status.railway.com/incident/QH8L8B3E) 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](https://www.bleepingcomputer.com/news/security/opencode-hack-exposes-api-keys-amid-ai-distillation-attacks/).

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](/blog/railway-security-incident-october-2026),
[OpenCode](/blog/opencode-security-incident-october-2026), and
[APITemplate](/blog/apitemplate-security-incident-october-2026).

## 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.

![An application sends a placeholder and limited broker authorization to a separately controlled broker. The broker holds the upstream key and sends an authenticated request to the API provider. Allowed requests still need limits.](/blog-assets/october-2026-api-key-security-roundup.png)

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](/docs/guides/agent-proxy) 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](/blog/railway-seekrit-deployment-patterns) to map the
application, broker, and provider, then decide which credentials and
administrative permissions must move to make the separation real.