Secretive: SSH keys that live inside your Mac's Secure Enclave

The problem Secretive solves for Mac SSH users

The usual SSH setup is a private key file on disk protected by file permissions. The README calls that fine in most cases and then explains the gap: it is not hard for malware or another user with access to the machine to copy the private key. Once copied, the key works from anywhere, and nothing on the original machine can tell you it happened.

Secretive targets that specific failure. It generates and manages SSH keys through the Secure Enclave, and the README states that keys protected this way are impossible to export by design. The audience is narrow and clear: people who do their SSH work from a Mac that has a Secure Enclave, and who would rather lose the ability to copy a key than keep the ability to have it stolen. That trade is the whole product.

How the Secure Enclave holds the key and what signs the request

The key material is created inside the Secure Enclave and never leaves it. What the rest of the system sees is a reference to that key, and signing happens inside the enclave rather than in the SSH process. The README also notes that Secretive still relies on Keychain APIs to store and access the keys, and that the Keychain restricts reads to the app that created them, identified by bundle ID. That detail is the reason the README warns that anyone building from source must stay consistent about which bundle ID they use, otherwise the Keychain cannot locate the keys that were created earlier.

Access control sits on top of that. On a Mac with a Secure Enclave, the README says you can configure keys so they require Touch ID or Apple Watch authentication before they are accessed. Secretive also posts a notification whenever a key is used, which turns a silent signing operation into something you can see. For Macs without a Secure Enclave, the README describes a fallback: configure a smart card such as a YubiKey and use it for signing instead. That fallback is a different security model, since the key lives on a removable device rather than in a chip soldered to the logic board.

Installing Secretive and creating your first key

The README gives two installation paths. The first is a direct download from the project's Releases Page. The second is Homebrew:

brew install secretive

After that command completes, Secretive is installed as a macOS app. Launch it and the app window is where keys are created and managed. The README's screenshots show the app's key list, a Touch ID prompt during authentication, and a notification when a key is accessed; those are the three surfaces you will actually interact with.

When you create a key, you choose whether it requires authentication before use. If you enable that, the next time something asks for a signature you should see the Touch ID prompt shown in the README rather than an immediate signature. The README does not walk through editing ssh_config or adding the key to an agent, so treat the app's own key management as the starting point and check the linked FAQ for the operational details it does cover. What you should not expect is a private key file you can copy somewhere. There is no export step in the README, and the section on backups explains why.

The backup and migration problem is the point, not a bug

Secretive's hardest constraint is stated plainly in the README: secrets in the Secure Enclave are not exportable, so they cannot be backed up and cannot be transferred to a new machine. The README's advice is to create a new set of secrets on the new Mac.

That is not a defect to work around, it is the mechanism doing its job. But it has consequences the README does not soften. If the Mac dies, the key is gone, and every server, Git host, and remote account that trusted the corresponding public key needs the new public key installed before you can get back in. If your only path into a production host is an SSH key held in the enclave, that host is one hardware failure away from being unreachable through that key. The README does not document a recovery or escrow procedure, and none should be assumed. Anyone evaluating Secretive should plan for the migration before they need it, not after.

There is a second boundary worth naming. A key that cannot be exported also cannot be handed to a CI runner or a shared build machine. Secretive is a tool for a person at a Mac, not for automation.

Where Secretive is the wrong tool

If your workflow depends on a private key you can copy to a server, load into a container, or check into a secrets manager, Secretive cannot serve it. The README is explicit that export is impossible by design, so any pipeline that expects a key file has no path through this app.

Shared infrastructure is the other mismatch. A build agent that needs to sign or authenticate over SSH needs its own key material, and a key bound to one person's Secure Enclave and gated behind that person's Touch ID is not something a headless process can use. The same applies to a team that rotates a single deploy key across machines.

Finally, the smart card fallback should not be read as equivalent. The README offers it for Macs without a Secure Enclave, but a key on a YubiKey is portable by nature, which is exactly the property the Secure Enclave path removes. If portability is what you want, the enclave path is not for you, and you should pick one model deliberately rather than assuming they behave the same.

How Secretive differs from sekey and from plain key files

The README credits sekey as the project that inspired Secretive, so the two share a premise: use the Secure Enclave to hold SSH keys instead of a file on disk. Secretive's own additions, as the README describes them, are around the user-facing side of that premise: access control through Touch ID or Apple Watch, notifications when a key is accessed, and a smart card option for Macs without an enclave.

The other comparison is the one most readers already live with, an unencrypted private key in ~/.ssh guarded by permissions. The difference is not speed or convenience, it is what an attacker gets. A copied key file works forever from anywhere and leaves no trace on your machine. A key in the enclave cannot be copied out, and with authentication enabled it cannot be used without a physical gesture on your Mac. The cost is that you give up portability and backup entirely. Whether that exchange is worth it depends on how much you value being able to move the key.

Maintenance, licence, and what the build process tells you

Secretive is MIT licensed, which is permissive and places few obligations on anyone who reuses the code beyond preserving the licence notice. Nothing in the README suggests the licence interacts with the Secure Enclave or Keychain behaviour; those are Apple platform constraints, not licence terms. This is a description of the licence, not legal advice.

The last push to the repository was on 2026-09-21, and the release list shows v4.0.0 dated the same day, following v3.0.4 in November 2025 and v3.0.3 in October 2025. The repository is not archived. On upgrade cost, the README describes an auditable build and release process: builds are produced by GitHub Actions, and starting with Secretive 3.0 they are attested using GitHub Artifact Attestation, with attestations viewable in the build log and on the project's attestation page. That matters more than usual here, because you are trusting this app with keys that cannot be rotated by copying a file. If you build from source instead of installing a release, the README's warning about consistent bundle IDs applies directly: change the bundle ID between builds and the Keychain will not find the keys you already created.

Editorial conclusion

Adopt Secretive if you do your SSH work from one Mac with a Secure Enclave and you want private keys that cannot be copied off the disk, optionally behind Touch ID or Apple Watch. Do not adopt it if you need a key you can back up, move to a new machine, or share with a build server, because the README states Secure Enclave secrets are not exportable. Before you commit, verify that your Mac reports a Secure Enclave, decide whether you will sign with Touch ID or with a smart card on a machine that lacks one, and confirm the bundle ID you intend to use if you build from source rather than installing the release.

Frequently asked questions

Official sources

1. License: MIT
2. maxgoedjen/secretive on GitHub
3. Project website
4. README
5. Releases