Security, keys & code.

Every developer knows the feeling. You paste an API key into your code "just for testing," it ends up in a git commit, and seconds later it's live on GitHub. Bots scan repos constantly. Your bills spike. You rotate. Repeat next month.

The gap in the market

There are two categories of tools that help with API key security:

1. Pre-leak prevention — Vault, dotenv, GitHub secret scanning. These keep keys out of code and logs.
2. Post-leak response — rotating the key, monitoring for abuse, revoking tokens.

What's missing is the middle: what if the key leaks, but it's already useless?

How Worthless works

Worthless splits your API key into two cryptographic shares. Neither share reveals anything about the original key — you need both to reconstruct it. Reconstruction happens in memory only, for milliseconds, and only when your app actually needs to make an API call.

$ worthless lock
1 key(s) protected.

$ worthless wrap python app.py
# your code is unchanged

$ worthless unlock
1 key(s) restored.

There's also a budget enforcement layer: if your spending limit is hit, the key simply never forms — even if your code tries to use it. A hard stop.

"Every secrets tool protects the key until your app uses it. Worthless protects you after it leaks."

Get started

pip install worthless
worthless lock
worthless wrap python app.py

When we say "a leaked share is worthless," we mean it in a precise mathematical sense. This post explains why — without requiring a cryptography background.

The intuition: a lock with two keys

Imagine a padlock that requires two keys simultaneously to open. If someone steals one, they can't open the lock. They have something real — but it's useless without the other half. Secret sharing is the mathematical equivalent.

The XOR method (2-of-2 sharing)

1. Generate a truly random string A the same length as your secret S
2. Compute B = S XOR A
3. Store A locally, B in the proxy

Reconstruction: S = A XOR B. Simple. Brilliant.

Why is A useless alone?

Because A is purely random. An attacker with only A sees that every possible value of S produces a valid B — the share A is statistically independent of S. It could have come from any secret equally well.

What Worthless does in practice

When you run worthless lock: your key is read, Share A is generated randomly, Share B is derived so A XOR B = key. A goes to local encrypted storage; B lives in proxy memory. Your .env is updated to point at the proxy. The full key exists for milliseconds, then memory is zeroed.

API key leaks are more common than people admit. Most companies quietly rotate and move on. Here are five categories of real incidents that show exactly how these leaks happen and what they cost.

1. The .env commit

With Worthless: the .env would contain only a useless key share.

2. The compromised dependency

With Worthless: the exfiltrated env var would be a key share — useless without the other half in a separate process.

3. The CI log exposure

With Worthless: the exposed env var would be a random-looking share. Logging it leaks only meaningless data.

4. The contractor offboarding gap

With Worthless: the contractor's copy contains a share tied to a local proxy — which is no longer running. Worthless without the other half.

5. The bug report screenshot

With Worthless: the visible string would be a random-looking share. A screenshot exposes nothing usable.

---

In every case, the attacker got a real, complete API key stored in plaintext. Worthless changes that — what gets leaked is never the whole key.

pip install worthless
worthless lock
worthless wrap python app.py