Stolen and resold
API keys

Spot stolen keys and reverse-proxy resale before the bill lands on your customer.

Decision trace

What it catches

1. Spread and bursts

   More than 10 prefixes or at least 3 countries in an hour. More than 5 prefixes in a minute.

2. A change in ownership

   Established keys whose recent traffic shifts to new networks or an unseen HTTP-tool family.

3. Leaked decoys

   Register canary key IDs, then plant decoys in repos, docs or bundles. Any reported use flags them.

Put the check at your gateway

const check = await nolgard.keyCheck({
  apiKeyId: authenticatedKey.id,
  ip: trustedClientIp,
  userAgent: request.headers.get('user-agent') ?? undefined,
  country: trustedCountry
});
if (check.decision !== 'allow') return rejectKey();
return runInference();

Send an opaque customer key ID, never the credential. IDs and IP prefixes are hashed per site. Usage reporting can detect after the fact; key-check gates before serving and counts the request. Pass the same ID to spend reservations to deny blocked keys with key_blocked.

Owner controls

The API keys panel lists findings, reason IDs and first/last flagged times. Clear a finding, manage decoy IDs and tune thresholds per site. New reasons send key.anomaly webhooks. Your backend handles credential rotation and revocation.

Limits

• Defaults are untuned starting points; they are no guarantee of detection.
• Shared NAT and corporate egress hide callers. CI fleets and mobile carriers may legitimately trip spread checks.
• Country checks require your supplied country. Missing signals skip their detector.
• A reseller behind one stable proxy can evade network checks. UA families are heuristic and carry no authenticated identity.
• Tool shift needs at least seven days and 200 baseline requests. New-network burst needs seven days. Canary checks have no warm-up.
• Key-check counts the attempt. Do not also report that request through usage unless double-counting is intentional.

Related

• Usage abuse
• Spend guard