An API key that is useless when stolen.

A single leaked API key, committed to a repo, printed in a CI log, caught in a screenshot, works from anywhere on earth. Binding the key's allowed origin to a roving IP makes a stolen copy fail closed everywhere but the box that owns it.

The problem

A provisioning box or CI runner holds a powerful credential, one that can register servers, change allowlists, move infrastructure. API keys are bearer tokens: whoever holds one is the owner. They leak in mundane ways. A committed .env, a verbose build log, a pasted snippet, a backup that ends up somewhere it should not. The moment a broad-scope key is exposed, it is usable from any IP, and you usually find out only after it has been abused.

Why it matters

The dangerous combination is broad scope plus global reach. Scope you have to grant for the key to do its job. Global reach is the part you can take away. If a key only authenticates from an origin you control, a leaked copy is inert everywhere else, and the blast radius of an exposure drops from "anyone, anywhere" to "no one, unless they are also on my box." It buys you time and turns a fire drill into a non-event.

How teams handle it today

• Rotate often and hope: good hygiene, but reactive. Between rotations a leaked key is fully live, and rotation only helps after you know.
• A secrets manager: protects the key at rest and in transit, which matters, but once the key is in use and then leaks, the manager cannot stop it being replayed from elsewhere.
• A static IP pin on the key: exactly the right control, defeated by reality: your provisioning box or runner does not always have one fixed, forever IP, so the pin breaks or never gets set.

How IPAuth does it

Mint the key with "lock to a roving IP" enabled. The box that uses the key reports its current public IP to IPAuth through a bookmark, the same auth-URL click as everywhere else. The key then authenticates only from whatever IP that bookmark currently reports. The allowed origin follows the box as it moves, so you get the safety of an IP pin without the brittleness of a hardcoded address, and a stale IP stops authorizing on its own after 24 hours.

The effect is concrete: a request carrying the key from the owning box succeeds; the identical key replayed from any other IP gets a 403 forbidden_origin on arrival, before scope is even considered. This is how we register every new server in our own fleet, one locked key on the provisioning box, useless the instant it leaves it.

Where it fits, and where it does not

Ideal for machine credentials with a clear home: provisioning boxes, CI runners, a deploy host, a cron server. It is origin binding, not a replacement for least-privilege scoping or rotation; do those too. It also assumes a roughly single-origin caller, so it is not meant for a key handed to many clients across many networks. For the high-value automation credential that lives on one box and must never be usable off it, locking the origin to a roving IP is the difference between a leak that matters and one that does not.