“The only way these things in our world ever get cared for is if there is someone out there that has a sense of responsibility for maintaining the world we live in… and takes it upon themselves to do something about it.” - Philosophize This [168], Ethics of Care
This application is a file-encryption experiment for the local AI agent threat model. The full working code is available at the GitHub link below. It is built using self hosted Supabase (Postgresql, Kong, etc), Nextjs, Tauri (Rust), and FastAPI (Python). Generative AI was used for some sections of code (particularly most of the frontend for the webapp and some of the fastAPI endpoints). This project is currently unaudited and provided as-is (MIT License). See the repo for the full disclaimer
Local AI software can read your files, API keys, images, and any other sensitive information on your device.
Some attempts have been made at minimizing the effects of this (see .llmignore); however, this is ultimately a handshake agreement between the tools and you. There is nothing fundamentally stopping a bad actor agent, prompt injection attacks, or even a good agent over-indexing from leaking secrets or sensitive data . More secure solutions have been offered, such as developing in VMs or working under different user spaces; however, Mythos has shown this can be broken out of by a powerful enough model according to Anthropic's red team.
Over the course of the last few months, I have worked on a possible solution. In short, the tool is self-service ransomware that encrypts your files while agents work. The basic flow is as follows:
.envs, testing files, data files with PII, etc.The full flow and code includes a number of additional safeguards against prompt injection attacks and bad actor AI tools:
The first step in the process is during sign up. Users create a 6 digit PIN and are then provided 6 “recovery seeds”. These are not account recovery keys; more on this below.
After a user selects all of the files they want to be protected for this “session”, they click a button to initiate. This sends a request from the client to the backend for a key that will be used in the AES-256-GCM encryption. Unlike other encryption softwares, this key is not random and is deterministically created with 4 inputs:
These four are then concatenated into a single string to be a seed for SHA256.
Below is a graphic, explaining the flow of the creation of a session key.
Tauri Client → FastAPI Server
[1] User initiates session, request for key sent to backend
FastAPI Server
[2] Deterministically create a SHA256 key for AES-256-GCM encryption (explained above)
FastAPI Server → Database
[3] Store session key in Postgresql
Database → FastAPI Server
[4] Confirm storage of session key
FastAPI Server → Tauri Client
[5] Return session key to Tauri Client
Local encryption cannot begin until key storage is confirmed from Postgresql
Having deterministically created, derivable keys may feel a bit like an anti-pattern for an encryption tool; however, because the threat model is exclusively for local AI agents, I believe it is a safe-trade off for the ability to recover files in the event of a database or logic failure. Even then, for a targeted, professional attack, the bad actors would still need to gain access to the fastAPI server secret, a user's recovery codes, a user's pin, and the device itself.
Upon receiving the session key, the desktop application can begin encrypting files. Each file goes through the pipeline below:
[1] Collect All File Stats
Before encryption begins, all protected file paths are gathered, sizes summed, and estimated length is created. This, along with the “actual”, is tracked for analytics to provide a better user experience. There is also a check done to ensure the files are all available, not open, and have not been deleted.
[2] Existing File to Checksum
Start with the existing, unaltered file. SHA256 checksum and send result to Postgresql. This can be used to ensure end-to-end integrity and no failure.
[3] AES-256-GCM Encryption
Run the actual encryption algorithm.
≤ 4MB: 12-byte nonce
> 4MB: 4MB chunks, 7 byte nonce
[4] Write Ciphertext
Randomize filename, add .annex extension. This is to hide sensitive file names. IE “CLIENT_TAXES_2026.csv” becomes “aj18xl.annex”
[5] Destroy Original File
Overwrite original file with random bytes, punch blocks, random rename (separate from step 4), fsync, and finally unlink. This process is TRIM aware and has different code paths depending on the operating system in use.
This level of care is taken as future proofing against stronger agents and bad actor tools that are capable of reading memory directly.
[6] Confirm File Completion
Send confirmation that the file has been encrypted, and securely deleted to the backend. Keeping a manifest of this allows for crash recovery.
After all files have been encrypted and originals destroyed, the session key is removed from memory using the zeroize crate in Rust. Best efforts are taken to ensure it no longer exists anywhere on the local machine.
Some additional measures are taken to encrypt relevant files. IE checking for temp files (.bak, .swp, etc.), VSCode backups, shell history, etc. This is all, also, best effort. Not all editors and third party softwares are explicitly handled.
The vast majority of ending a session is just… undoing the previous section. The one callout I would like to make is that decrypting requires inputting the PIN from signup. This means a malicious AI tool cannot attempt to make an API request to our backend asking for the session key to attempt decryption. The rate limit is also intentionally low to avoid brute force attacks.
Once the key has been received, filenames and contents are restored, and checksums are compared with what existed pre-encryption to ensure nothing was lost in the process.
Fullscreen is available. Hover and look to the top right.I believe this project can be used for a number of purposes. One abstract usecase would be for hiding test cases from AI agents so that they don't edit the tests to work rather than fix the actual code .
There are a number of additional safety measures that could be implemented for local AI safety, such as an egress firewall that blocks API calls that contain sensitive data or even partial file encryption that only blocks sensitive data. However, this project is a strong starting point.
Feel free to call me out on issues, improvements, or potential exploits that I may have overlooked.
Final note: Calling this "ransomware" is a joke about how it works, not what it's for. It only ever encrypts your own files on your own machine to keep them out of reach of local agents. There's nothing offensive here.