Security
Where credentials live, how releases are verified, and how to report a vulnerability. Your provider keys never leave your own machine.
Credentials never reach a client
Clients on your machine authenticate with the internal sq- key. The real provider credential is attached by the proxy at the last moment and is never visible to the caller.
Local storage
The data directory is created with 0700 permissions and holds a SQLite database. The management API refuses requests that do not originate from localhost.
Verified releases
Every binary is published with a SHA-256 checksum file and a detached signature. Verify both before running a build that will hold your credentials.
Plaintext at rest, and why
Credentials in the local database are not encrypted, deliberately. Disk encryption is the operating system’s job, and an application-level keychain would not move the boundary: anything running as your user can already read your home directory. What protects the file is what protects the rest of your home — 0700 permissions and your OS login.
The network boundary
The proxy listens on all interfaces so a trusted LAN can share one instance; the management API is stricter and refuses anything not originating from the machine itself. On an untrusted network, put a firewall in front of the port — the sq- key gates requests, but a gate is not a wall.
What is not collected
There is no telemetry, no crash reporting, and no request or response logging — prompts and completions are never written to disk. A security review of what leaves the machine is short: requests to the providers you connected, and nothing else.
Reporting a vulnerability
Email security@sharequota.com. Please give us a reasonable window to ship a fix before disclosing publicly, and we will credit you in the release notes unless you would rather we did not.