What If a Leaked API Key Simply Didn't Work?

On October 21, 2026, the hosting platform Railway reported that an intruder had accessed its systems and may have reached customer environment variables. According to Railway, the target was AI provider API keys. Providers such as OpenRouter worked with Railway to revoke keys that may have been exposed, and thousands of teams spent the next days rotating secrets.

Just days earlier, on October 16, an intruder reached a legacy system behind OpenCode Console, a hosted service where teams save their own OpenAI, Anthropic and Google keys. Those saved keys were exposed, and users soon reported charges they never made.

Source: The Hacker News · Cloud Security Alliance

The Problem: A Key Works From Anywhere

An API key is a bearer token: whoever holds it is you. The API can't tell whether a request comes from your server or from an attacker's laptop on the other side of the world. One leak, and the key works for anyone, anywhere, until someone notices.

Stored in one shared place: one breach exposes everyone

Valid from any IP, any machine, anywhere in the world

Long-lived: they keep working until someone rotates them

Rotation is manual, slow, and always after the damage

The Fix: A Private Hub Between Provider and Customer

Imagine an AI provider (OpenAI, Anthropic, OpenRouter, anyone who sells an API) running its endpoint inside a Ghost network. Each customer's servers join through a BiFrost Pass issued by the provider. From then on, the customer's key is accepted only when the request arrives through the Ghost network, from that customer's own devices.

1

The provider issues a BiFrost Pass to the customer

One pass per customer, limited to the machines that should call the API: production servers, CI, nothing else.

2

The customer's servers join the provider's hub

Each server gets a fixed, cryptographically bound identity on the Ghost network. It can't be spoofed or shared.

3

The API accepts the key only from those devices

Key + device. The key alone is just a string. A request from anywhere else never even reaches the API.

# Provider: give Acme's production servers access to the API hub

ghost-cli bifrost create --hub api-gateway --max-devices 5 --expires 720h

# Attacker with a stolen Acme key, from their own machine

curl https://api.provider.ai/v1/chat -H "Authorization: Bearer sk-acme-..."

✗ no route: the endpoint doesn't exist outside the Ghost network

The attacker walks away with thousands of keys, and none of them work.

Next Level: No Key at All

If the network already knows exactly which device is calling, why keep a key? Take a customer who uses OpenAI through OpenRouter:

1 The customer already has a private Ghost connection with OpenAI.

2 In the OpenRouter dashboard, they scan a QR code. OpenRouter joins that connection.

3 The devices are authorized and see each other. OpenAI knows the call comes from OpenRouter, on behalf of that customer, by the network itself.

No key to copy, store, rotate or leak. Remove the device, and access is gone.

Better Than an IP Allowlist

IP allowlists break with autoscaling, dynamic IPs and shared NAT, and one cloud IP can be shared by thousands of tenants. A Ghost identity belongs to one device, is bound to its keys, and follows it to any cloud, any IP, anywhere.

What You Can Do Today, in Your Own Systems

You don't have to wait for your providers. The same idea protects everything you run yourself:

Take internal services off the internet. Databases, admin panels and internal APIs answer only inside your Ghost network. A leaked password alone gets an attacker nowhere.

Let the network be the credential. Your services trust each other by device identity: fewer secrets in environment variables, fewer secrets to steal.

Isolate with Phantom Hubs. Group servers by role. A compromised machine reaches only its own hub.

Time-box and revoke. Give contractors and AI agents a BiFrost Pass that expires on its own, and cut off any device with one command.

ghost-cli hubs create --name databases

ghost-cli bifrost create --hub databases --max-devices 1 --expires 24h

ghost-cli devices revoke --id <device-id>

Or Just Ask Your AI Agent

With the Ghost MCP server, your agent does it for you: “Move the database servers into their own hub and give the contractor 24-hour access.” Done.