I want my AI tools to help with my work. That does not mean I want every piece of work available to them.
I built working vaults and hardware-key archives so I could decide when private files become available. Some work needs to be open while I use it. Some can stay sealed until I physically approve opening it again.
The important moment is when the files become readable. A locked archive protects its contents. Once I open it, which programs can reach them?
For the archives, that decision starts with something I physically hold: a security key. I want putting some work away to mean I have to reach for my real-life keys to open it again.
Which Files Can My AI Reach?
I use coding agents that can read files and run commands. That is useful precisely because they can do real work. It also makes me care about which files are sitting there, readable, before I have decided to work on them.
A private project does not need to be available to every tool all day. And when material must stay away from an outside AI service, opening the folder is not permission to send its contents to that service.
Telling an agent to leave a folder alone can help prevent mistakes. I also want access controlled by the system underneath it. If another command, another tool, or another account can read the same files, the instruction has not settled the access question.
This is where my FIDO key project and my vault project meet. FIDO is the technology behind many physical security keys people use to sign in. I have been using those keys for server administration, then extending the idea to encrypted archives and recovery copies of my vault keys.
Two Kinds of Putting Things Away
There is an important distinction in what I have built.
A working vault is for a project I expect to open regularly. My vault software asks an authorized person for a code from their phone before opening it. The server keeps the encryption key needed for that work. The phone code controls the supported opening process; it does not make the files cryptographically inaccessible to the server administrator.
A hardware-key archive is for putting a folder away under a different rule. The archive system encrypts it for my physical keys. It is configured with the public information needed to seal the archive, without the matching ability to reopen it on its own.
That second one is the folder that needs my real-life keys. More precisely, it is an encrypted package of the folder. Opening it restores readable files; it is not a magic folder icon that stays protected after I have opened it.
What Happens After I Open It?
The files become readable. Programs with access can read them, copy them, or send their contents elsewhere. Unplugging the key does not take those copies back, and closing a working vault does not erase material a tool has already saved outside it.
The recovery computer matters too. As the plugin's security notes explain, a stolen decryption identity from its memory can be used later without the token. I still need to trust the machine where I unlock the archive.
And archiving a folder does not automatically remove its original copy. Deciding what to keep, checking that recovery works, and retiring old copies are part of putting it away.
The Routine Matters as Much as the Lock
For a folder that must stay away from AI, this is the workflow I want:
- Decide what belongs inside. Include the working files, then check for copies in downloads, email attachments, synced folders, and tool histories. Locking one folder does not cover those other places.
- Choose where to open it. Use an account or environment where the AI tools that must not see the material cannot read it. A physical key controls opening; file permissions and isolation control access while it is open.
- Open it for the work. Approve the opening, use the tools appropriate for that material, and keep it out of AI prompts when that is the requirement.
- Close it when finished. Stop the programs using the files, seal the working vault, and check that it actually reports closed. Restoring an archive is different: the recovered folder stays readable until I separately put it away.
- Test recovery before retiring copies. Confirm that the backup and spare key work, then handle leftover files according to the project's retention requirements.
Mail and connected services need their own access decisions. A folder lock cannot stop a mail integration from reading a copy of the same document in an attachment.
How This Actually Works
The working-vault tool is called jts-vault. Its configuration lives in my justin-nix project. While closed, a vault is an encrypted archive. After an approved opening, the software restores the files into a temporary filesystem in memory, where permitted user accounts can work with them.
Closing it creates and verifies an encrypted snapshot before removing the working copy. The system also records openings and closings, so I can see who opened a vault and how long it was available. That measures exposure time; it does not prove someone was working for every minute.
The archive tool, jts-archive, handles folders I want to seal for later. It packages a folder and encrypts it using age, a file-encryption tool. The hardware-key connection comes from age-plugin-fido2-hmac. It needs a compatible FIDO2 key with a feature called hmac-secret; being a USB security key alone is not enough.
In the mode I use, encryption needs only the public recipient information. Decryption needs the matching physical key and its approval. This lets a server create encrypted archives while I keep the physical keys elsewhere.
The plugin uses the token to make an age decryption identity available in the recovery computer's memory. It does not keep that identity permanently inside the token. The project documents this limitation and currently labels the plugin experimental.
The Backup Needs Its Own Key Plan
A working vault has an obvious backup problem: copying its encrypted files and the key that opens them into the same unprotected backup hands over both pieces together.
My setup makes a separate encrypted recovery copy of the vault keys, protected by the physical security keys. That is what the configuration calls "identity escrow." In ordinary language, it is a locked backup of the keys that open the working vaults.
There is a detail here that is easy to miss. My recovery setup uses a separate identity file alongside each physical key. The file tells the software how to use that key for this encryption setup. Holding the token without the matching file is not enough.
So the recovery kit needs the encrypted backup, an enrolled physical key, its matching identity file, and any required PIN. The matching file needs a recoverable copy away from the computer I might lose.
I enrolled a second key separately. Either enrolled key can open a backup encrypted for both; this is a spare-key arrangement, not a requirement to present two keys together. The project's recovery notes record a successful readback with the backup key. That is a much more useful check than watching a backup file appear.
A Small Moment of Friction I Actually Want
I spend a lot of time making computers do things with fewer steps. This is a step I want to keep.
A working vault lets me choose when private work is available. A hardware-key archive lets me put material away with the opening key physically elsewhere. Both give me a more deliberate relationship with what my tools can reach.
Sometimes I want opening a folder to start with reaching for my keys.
Header photo by rc.xyz NFT gallery on Unsplash.
Content on this blog was created using human and AI-assisted workflows described in my standards and workflow posts. Original ideas and editorial decisions by Justin Quaintance.