BYOK — Bring Your Own Keys

Furx is a pass-throughorchestrator. Your provider keys go from your machine directly to the provider over HTTPS. We don't run a proxy, don't see your prompts, don't see your responses, and don't bill your provider quotas.

Where keys live

All three are user-scoped, OS-encrypted at rest, and require user login session to read. Furx does not have a fallback to plaintext file storage — if Keychain is unavailable, the wizard fails closed.

What we never store

See Privacy Policyfor the full list of what we do/don't collect.

What does cross the network

Once you opt-in (Pro only):

Provider-side: where your data goes

When you dispatch a prompt, Furx opens an HTTPS connection from your machine straight to the provider you picked. Examples:

You are responsible for the provider's TOS, data-retention policy, and rate limits. Use a local model (Ollama) if your data can't leave your machine.

Council Mode and BYOK

Council Mode dispatches in parallel to multipleproviders. Each request uses its own key. We never multiplex multiple users' keys, never share connections, never warm-pool credentials.

You can build a Council preset that's 100% local (Ollama models only) — that's the privacy moat for legal / regtech / finance teams.

Rotation & revocation

Update a key via Furx Connect(Settings → Connect → pick provider → Update key). The old key is overwritten in Keychain; nothing is cached in memory longer than the request that's in flight.

To fully revoke: delete via wizard, then revoke at the provider side (you control that). Audit log entries reference key aliases, never the secret itself.

Multi-tenant / Team mode

On Team subscription, each seat's Keychain is independent. Centralized policy (allow-listing, spend caps) is enforced via the proxy URL — not by Furx seeing the keys. Use LiteLLM or your own gateway as the proxy target.

Next