Free & Open Source

Eliminate .env File Leaks
With Hardware-Bound Encryption

No master passwords. No key management. Secrets encrypted to your hardware fingerprint.

How Liberty Works

Liberty generates a unique fingerprint from your system's hardware characteristics—CPU, machine ID, disk serial, and platform details. This fingerprint derives an AES-256 encryption key using PBKDF2. Your secrets are encrypted with AES-GCM, providing both confidentiality and tamper detection.

The result: secrets that can only be decrypted on the machine where they were created. Copy the vault to another machine and it's useless. No master password to remember. No key server to manage. It just works.

The Encryption Flow
Hardware Fingerprint → PBKDF2 (SHA-256, 100k iterations) → AES-256 Key → AES-GCM Encrypt → Encrypted Vault
Features

Hardware-Bound Encryption

Secrets are bound to your hardware via a software PUF (Physically Unclonable Function). Stolen files are useless on any other machine.

AES-256-GCM

Industry-standard authenticated encryption. Provides both confidentiality and integrity—any tampering is immediately detected.

Zero Configuration

No master passwords, no key files, no config files. Install, init, add secrets. Liberty derives everything from your hardware.

Environment Injection

Run any command with secrets injected as environment variables. Your application code reads process.env or os.environ as usual.

Complete Audit Trail

Every secret access and modification is logged. Know exactly when a secret was read, updated, or injected into a process.

Safe to Commit

The encrypted vault is safe to commit to git. It's hardware-bound and encrypted—useless to anyone who doesn't have your machine.

Quick Start

Install

# Install from PyPI pipx install liberty-secrets # pipx not installed? Use: pip install --break-system-packages liberty-secrets

That's it. The liberty command is now available globally.

Prefer to install from source? Clone the GitLab repo.

Three Steps. That's It.

# 1. Initialize the vault (one time — binds to this machine's hardware) liberty init # 2. Add your secrets liberty add API_KEY sk-1234567890abcdef liberty add DATABASE_URL postgresql://localhost/mydb # 3. List what you have liberty list - API_KEY - DATABASE_URL # 4. Run your app with secrets injected liberty exec -- npm start liberty exec -- python manage.py runserver

Your application reads secrets from environment variables as usual— process.env.API_KEY in Node.js, os.environ['API_KEY'] in Python. No code changes needed.

Commands
Command Description
liberty init Initialize an encrypted vault
liberty add KEY value Add or update a secret
liberty list List all secret keys (not values)
liberty show KEY Display a secret's value
liberty exec -- cmd Run a command with secrets as environment variables
liberty audit View the audit log of all secret access
Why Not Just .env Files?
Feature .env Files Liberty
Encryption Plaintext AES-256-GCM
Git Safety Easy to leak Safe to commit
Hardware Binding Works anywhere Bound to hardware
Master Password N/A Not needed
Audit Trail None Every access logged
Portability Easy to share Not portable (by design)
Security Model

What Liberty Protects Against

  • Accidental git commits of secrets
  • Secrets stolen from disk backups
  • Secrets copied to different machines
  • Tampered vault files (GCM authentication tag)

What Liberty Does Not Protect Against

  • Attackers with root access on your machine
  • Memory dumps while secrets are in use
  • Physical hardware theft (attacker can use your machine)
Best Practice: Liberty is designed for local development secrets. For production, use proper secret management (AWS Secrets Manager, HashiCorp Vault, etc.). For CI/CD, use platform secrets (GitHub Actions, GitLab CI/CD Variables).
Liberty + LockStock: Better Together
Liberty is the configuration layer for LockStock. Store once, deploy everywhere—no .env files, no Docker flags to remember.

The Setup: 60 Seconds

Store your LockStock keys in Liberty once. From that point on, every gateway operation reads from the vault automatically. Agent IDs are written back to Liberty when you provision, so everything stays encrypted and hardware-bound.

# Store your infrastructure keys in Liberty (one time) liberty add LOCKSTOCK_API_KEY "lsk_admin_..." liberty add LOCKSTOCK_GATEWAY_KEY "lsk_gateway_..." # Extract the gateway CLI from the admin-tools image (one time) mkdir -p ~/.local/bin docker run --rm registry.gitlab.com/d3cipher/lockstock-images/admin-tools:v4.19.2 \ cat /usr/local/bin/lockstock-gateway > ~/.local/bin/lockstock-gateway && \ chmod +x ~/.local/bin/lockstock-gateway # Provision a new agent — all config is per-agent, all flags required lockstock-gateway provision \ --name SUPPORT_BOT \ --provider anthropic-native \ --apikey "sk-ant-..." \ --upstream "https://api.anthropic.com" \ --gui theia \ --mcp-dir /home/you/your-project \ --tasks CHATCOMPLETION,FILEREAD,SHELL ✓ Agent agent_a3f7b2c1_support_bot provisioned ✓ Wrote 6 keys to Liberty vault # Start the gateway — reads per-agent keys from Liberty, launches Docker lockstock-gateway start ✓ Gateway running on port 4000 with 1 agent

What This Means

No .env Files

API keys, account keys, agent IDs—all encrypted in Liberty's vault. Nothing in plaintext. Nothing in shell history. Nothing to leak.

One Command Deploy

lockstock-gateway start reads all config from Liberty, picks up every agent you've provisioned, and launches the Docker container. No flags. No env vars to remember.

Multi-Agent from Day One

Each agent gets its own Liberty key (LOCKSTOCK_AGENT_<NAME>). Provision as many as you need. The gateway routes them all.

Hardware-Bound Agents

Agent IDs, API keys, and your Account Key are all encrypted to your hardware. Copy the vault to another machine and you get nothing—no agent identity, no stamping authority, no transcript decryption. The agent is effectively hardware-bound, not because LockStock enforces it, but because the credentials needed to operate it are.

Two Audit Trails, One Story

Liberty and LockStock each keep an audit trail, and together they tell the complete story:

Liberty Audit

Who accessed which keys, when. Local, hardware-bound, tamper-evident. You can see every time the gateway read an agent ID or API key.

# liberty audit 11:44:33 | tori | secret_accessed (key=ANTHROPIC_API_KEY) 11:44:33 | tori | secret_accessed (key=LOCKSTOCK_AGENT_CLAUDE_D3CIPHER)

LockStock Audit

What the agent did with those keys—every action, cryptographically chained. Tamper-evident, server-side, exportable for compliance review.

# dashboard → audit logs seq: 601 | agent_0d20202e_claude_d3cipher task: CHAT_COMPLETION | hash: 3d9e4f...

Clone Protection: Three Layers Deep

When Liberty and LockStock work together, your agents get three independent layers of clone protection that no single product provides alone.

Layer What It Does When It Acts
Prevention Credentials are encrypted to your hardware. Copy the vault to another machine and decryption fails. Before any credential is exposed
Enforcement The server verifies the machine fingerprint on every request. Wrong machine, hard rejection. At request time, before the action proceeds
Detection The cryptographic chain catches forks. Two callers can't both extend the same chain. At chain level, if all else fails

Free forever. MIT licensed.

Stop committing plaintext secrets. Start encrypting them to your hardware.

View Source on GitLab See LockStock — AI Agent Security Gateway Quickstart Guide