A new Python tool called AiLock is attempting to solve a problem that more developers are starting to face as AI coding assistants become embedded in their workflows: how do you keep sensitive code hidden from AI tools that index your codebase, while still being able to run and develop with that same code normally? The answer, according to creator lo2589, is memory-only decryption—encrypting files on disk so filesystem-level reads see only ciphertext, but letting the AiLock runtime decrypt everything in-process when you actually want to execute.

How It Works

When you run ailock lock secret.py, the file gets encrypted in place. From that point forward, tools like GitHub Copilot's codebase indexing, grep searches, or any AI assistant using read_file or cat operations see only binary ciphertext. But calling ailock run secret.py starts a Python process where AiLock intercepts imports and file I/O operations—decrypting the locked modules in memory before executing them, with no plaintext ever written back to disk. The same transparency applies to data files: if config.json is locked, calls like open("config.json") or Path.read_text() inside your running program automatically get decrypted content without any AiLock-specific code in your application.

Security Model and Realistic Expectations

AiLock explicitly targets filesystem-level AI access—a coding assistant that reads files through ordinary system calls will see ciphertext. It does not claim to stop a fully informed local adversary who can run arbitrary commands, capture process memory, or trick the user into decrypting files. The documentation recommends combining AiLock with OS-level execution policies and process isolation for stronger guarantees on sensitive workloads. This is honest framing that matches what you'd expect from security-aware developers: it's one layer of defense, not a magic shield.

Cryptography Underneath

The implementation uses Argon2id for deriving encryption keys from your password, ChaCha20-Poly1305 for authenticated encryption of individual files, and independent random keys per file wrapped with password-based key derivation. Optional recovery keys can be generated at lock time for emergency access if passwords are lost. Backups go into encrypted ZIP archives under .ailock/backups/ by default—plaintext never touches disk in the standard workflow.

Available Commands

ailock open . launches a tkinter-based GUI editor where you can inspect and edit locked files through a plaintext viewport, saving writes encrypted content back to disk. ailock show secret.py prints decrypted content to stdout without modifying anything. When you're ready to commit or deploy, ailock unlock secret.py restores plaintext on disk (with optional backup). There's also ailock freelock, which starts a JSON-RPC workspace server for programmatic controlled access—useful if you want external tools to interact with locked code through an explicit API rather than direct filesystem reads.

Who This Is For

If you're working with proprietary algorithms, API keys embedded in configuration files, or just want to keep internal utilities out of the training data that AI assistants collect, AiLock provides a friction-reduced workflow compared to traditional encryption schemes where you'd decrypt everything before touching it. The Python 3.11+ requirement and MIT-licensed codebase make it straightforward to integrate into existing projects.

Key Takeaways

  • Files stay encrypted on disk; only the running process sees plaintext in memory
  • No code changes required—standard imports and file operations work transparently
  • Targets AI/filesystem-level access, not adversarial local attackers with memory inspection capabilities
  • Uses solid crypto: Argon2id + ChaCha20-Poly1305 with per-file keys

The Bottom Line

AiLock is a clever approach to a real problem emerging as AI assistants become default tools in development environments. It's not paranoia—plenty of legitimate reasons exist to keep certain codebases out of AI indexes, whether for competitive advantage, compliance, or just not wanting your half-baked experiments training the next model update. Worth evaluating if you're serious about controlling what your coding assistant can see.