Security you can verify means showing our work, including the parts we had to improve. We review the code that runs on your machine the way an attacker would, then publish the findings and the fixes. Here is the most recent audit.
Audit dateAugust 2026
ScopeKryptic daemon - local socket, token storage, and self-update
Findings3 identified · 3 resolved
We run our own adversarial reviews of the code that runs on your machine. This audit examined how the daemon serves secrets over its local socket, how it stores your session, and how it updates itself. Below is exactly what we looked for, what we found, and the fix we shipped for each item.
Findings
Each issue, its risk, and the shipped fix
Local socket
The daemon served secrets without authenticating the caller
High
The risk
The daemon delivered secrets to any process that could open its local socket. The only barrier was the socket file permission, so any program running under the same operating-system account could ask for a project bundle and read the secrets in plaintext. There was no check of which program was actually connecting.
The fix
Every connection is now authenticated by operating-system credentials before a single byte is read. On macOS and Linux the daemon reads the caller’s user id straight from the kernel (LOCAL_PEERCRED / SO_PEERCRED) and serves only a process running as the same user; on Windows the named pipe’s security descriptor enforces the same rule. These credentials are recorded by the kernel at connection time and cannot be forged by the caller. Unauthorized connections are dropped without a reply.
Resolved
Self-update
The updater did not constrain where binaries were downloaded from
Medium
The risk
The self-updater trusted the download locations advertised in the release metadata. A tampered response could, in principle, point the binary or checksum download at a server we do not control.
The fix
Updates are now fetched only over HTTPS from GitHub’s own hosts; any other scheme or host is rejected before anything is downloaded. The existing checksum verification of the downloaded binary is unchanged, so a download still has to match the published hash.
Resolved
Local socket
A brief window while the socket was being created
Low
The risk
The socket was created with the process default permissions and tightened a moment later. That left a very short window in which, on a shared machine, it could theoretically be reached by another account before the permission was applied.
The fix
The socket is now created with restrictive permissions from the outset, so the window no longer exists. The explicit permission tightening remains in place as a second layer of defense.
Resolved
Hardening in progress
What we are still improving
Binding your session to the signed daemon
Your session token already lives in your operating system’s credential store (Apple Keychain, Windows Credential Manager, or libsecret), protected by your user account like every other credential there. We are working toward binding that entry to the signed daemon binary so that even other programs in your own account cannot read it.
End-to-end signed releases
Every update is verified against a published checksum today. We are adding cryptographic release signatures so a binary’s authenticity is provable on its own, independent of where it was downloaded from.
Every fix on this page is in the open-source code you can read yourself, and the daemon, encryption engine, and language packages are all public. If you find something we missed, we want to hear about it: report suspected vulnerabilities to [email protected]. We acknowledge within 48 hours and credit reporters who want to be credited.
