Security, without hand-waving

How KeyKing protects AI API keys

KeyKing AI is designed so the desktop credential workflow happens on your machine. Keys are encrypted at rest, decrypted locally when needed, and sent only to the upstream provider selected for a request.

Credential flow

Provider API key
  → AES-256-GCM encrypted local vault
  → local KeyKing proxy
  → selected provider API
  → response to your application

Encryption at rest

The documented desktop design uses AES-256-GCM with a random 12-byte nonce. Password-based derivation uses PBKDF2-HMAC-SHA256 with 310,000 iterations.

Decryption boundary

The selected credential is decrypted locally when KeyKing needs to authenticate an upstream request. Plaintext credentials should not be written to logs.

What providers see

The selected model provider receives the request content and credential required to serve it. That provider's privacy, retention, and security terms still apply.

What KeyKing does not solve

KeyKing cannot protect an already compromised machine. Malware or an attacker with sufficient local access may observe memory, traffic, or unlocked credentials.

Local proxy vs serverless SDK

Concern	Desktop proxy	Serverless SDK
Where it runs	Developer machine	Application runtime
Vault use	Local desktop vault	Exported encrypted vault
Plaintext lifetime	In local process memory when required	In runtime memory when required