What if a security application didn't need your email?
No account.
No cloud dashboard.
No telemetry.
No subscription.
Just a Windows executable running locally on your machine.
That's the philosophy behind ATLOCK v4, a Windows security suite I've been building as a solo developer.
👉 Try ATLOCK v4: [https://akhouri-anmol-kumar.github.io/Akhouri-systems/]
Why local-first?
Security software has an interesting paradox.
You install software to protect your machine...
...and then the software asks you to send information to another machine.
I wanted to experiment with a different architecture.
ATLOCK is designed around a local-first model:
┌───────────────────────────────┐
│ ATLOCK v4 │
├───────────────────────────────┤
│ │
│ 🔒 System Lockdown │
│ 🛡️ NTFS File Protection │
│ 🔑 Password Vault │
│ 📸 Intruder Ops │
│ 🔔 Local Security Alerts │
│ │
├───────────────────────────────┤
│ LOCAL WINDOWS PC │
└───────────────────────────────┘
No cloud dependency
No account required
The idea is simple:
Keep security-sensitive operations close to the machine they're protecting.
🔐 1. Password Vault
ATLOCK's password vault uses authenticated encryption through Fernet, with key derivation using PBKDF2-HMAC-SHA256.
The important architectural idea isn't simply:
"We use encryption."
It's:
How do we protect the encryption key and make the entire storage pipeline local?
The vault is designed so credentials remain stored locally rather than being synchronized to a remote service.
That removes an entire category of cloud-side concerns.
🛡️ 2. NTFS File Protection
Windows already has a sophisticated permissions model.
ATLOCK works with Windows' NTFS security model / ACLs rather than pretending that a custom encryption layer is automatically superior to the operating system.
That's an important distinction.
A security application shouldn't reinvent every primitive.
Sometimes the better engineering decision is to use the security mechanisms Windows already provides and build useful functionality around them.
📸 3. Intruder Ops
This was one of the more interesting modules to build.
ATLOCK can respond to repeated unauthorized access attempts with locally stored evidence and alerts.
The workflow is roughly:
Failed authentication
│
▼
Attempt counter
│
▼
Threshold reached?
/ \
NO YES
│ │
│ ├── Security alert
│ ├── Webcam capture
│ ├── Optional recording
│ └── Local evidence
│
└── Continue monitoring
One engineering problem here was not letting hardware operations freeze the main UI.
Camera initialization can be unpredictable.
A security event shouldn't make the application interface hang.
So capture work needs to be handled separately from the main interface flow.
⚙️ 4. Portable architecture
ATLOCK is distributed as a Windows executable rather than requiring a conventional installation process.
That makes the deployment model simple:
Download
↓
Run
↓
Configure
↓
Use
No account creation.
No server setup.
No cloud console.
No installer dependency.
🧠 The bigger experiment
ATLOCK isn't supposed to replace BitLocker, Windows Security, enterprise EDR, or dedicated password managers.
That would be a ridiculous claim.
Instead, I'm exploring something different:
What can one local Windows security application realistically bring together without turning into a giant cloud-dependent platform?
That question has shaped most of the architecture.
And honestly, building it taught me something important:
Security isn't just about adding more features.
Every feature introduces:
more code
more dependencies
more attack surface
more failure modes
more things to maintain
So sometimes the strongest architectural decision is actually:
Don't add another dependency unless you need it.
🔒 Local-first is a design decision
ATLOCK doesn't ask users to trust a remote backend for its core security functionality.
That's intentional.
I'm interested in the idea that a security application should minimize the amount of information that needs to leave the machine in the first place.
Not because cloud software is inherently bad.
But because:
Data you never collect is data you never have to protect.
🚀 ATLOCK v4
Current focus:
🔒 Windows system lockdown
🛡️ NTFS-based file protection
🔑 Local encrypted password vault
📸 Intruder detection
🎥 Local security evidence
🔔 Security alerts
⚙️ Portable Windows deployment
🖥️ Local-first architecture
If you're interested in Windows security, desktop engineering, privacy-first software, or just want to see what a solo developer can build, I'd genuinely appreciate you trying it.
ATLOCK v4 → [https://akhouri-anmol-kumar.github.io/Akhouri-systems/]
And if you download it, I'd especially like to hear:
What security feature would you add to a local-first Windows security suite?
ATLOCK
"We Build What Others Forgot To Fix"
Top comments (2)
The NTFS/ACL point is the one I'd highlight most, "use what the OS
already gives you instead of reinventing it" is the right instinct,
and it's the opposite of what a lot of solo security projects do when
they try to prove technical depth by rebuilding primitives that are
already battle-tested.
One thing I'd want to understand better on the vault: PBKDF2-HMAC-SHA256
derives the key, but where does the master passphrase/key live between
app launches, is it re-entered every session, or cached somewhere on
disk? That's usually the actual weak point in local password vaults,
not the encryption algorithm itself.
The intruder-ops webcam capture is a cool feature, though I'd flag
that as the one area worth being extra careful with, false positives
capturing footage of the wrong person, and where that evidence is
stored/who can access the binary matters a lot given what it's
capturing.
Respect for keeping this local-first end to end though, that's a
genuinely harder constraint to design around than "add a cloud
backend and call it done."
Thanks a lot for the detailed feedback — especially the NTFS/ACL point. That was exactly the reasoning behind using Windows' existing security model rather than trying to reinvent a lower-level primitive.
For the password vault, you're right that the key-management side is arguably more important than just saying “Fernet + PBKDF2.” In the current implementation, the master passphrase is [re-entered each session / stored using X] rather than being treated as something that should simply sit around in plaintext on disk. PBKDF2 is used to derive the encryption key from the passphrase, while Fernet handles the authenticated encryption.
Your Intruder Ops point is also fair. Webcam capture introduces a completely different privacy/threat-model consideration. False positives, who can access the captured evidence, and protecting the evidence directory are all things I need to be very deliberate about. The current design keeps the captured media local, but I agree that “local” by itself doesn't automatically mean “secure.”
That's actually one of the things I like about building ATLOCK locally: security decisions don't end at choosing an encryption algorithm. The surrounding key management, permissions, storage, failure cases, and privacy implications matter just as much.
Really appreciate you digging into the architecture instead of just looking at the feature list. 👊