Security & Privacy

Each signed-in user has an individual account — email and password — with password reset links delivered over email (or surfaced to an admin when SMTP isn't configured). Signed-in sessions carry a short-lived bearer token, and every action that spends money or changes configuration requires it.

Anonymous guests can run a small number of searches for evaluation; admin operations additionally require the admin token, sent as an X-Admin-Token header. Always sign in over HTTPS on public deployments.

• Keys are stored in the server-side database, never in source code or container images
• API responses mask keys — only the first and last four characters are ever shown
• A stored key can only be sent to the provider endpoint it was configured for
• Deleting a provider removes its key from the database immediately

Queries are sent only to the providers you configure, over their official APIs. Run history and provider config live in your deployment's own database — on your infrastructure if you self-host. There is no analytics, telemetry, or third-party tracking in the app.

• Rotate any key that was ever committed, pasted into a ticket, or baked into an old image
• Prefer providers' usage-limited or project-scoped keys over master keys
• Serve over HTTPS only — credentials and keys otherwise travel in plaintext
• Review your provider dashboards periodically for unexpected usage