Auto Secure LoginPlatform
Live Zero runtime dependencies Shared infrastructure

A vault you can fill while it's locked.

ASL Vault is a sealed credential store with a deliberate asymmetry: writing needs only the public key; reading needs your passphrase. Automation files new secrets continuously while the vault is sealed — and is structurally unable to read anything already stored. Compromise a writer and it leaks nothing. Only the operator, with the master passphrase, can unseal and reveal, one secret at a time, every reveal recorded in a tamper-evident audit log.

write ≠ readsealed writes, passphrase reads
0runtime dependencies
AES-256-GCMover X25519 sealed boxes
genesishash-chain verified from row one

The problem

Your secret store is only as safe as the machines that write to it.

Every CI job, deploy script, and provisioning task that creates a secret typically also holds the keys to read the whole store. One compromised writer and the vault is open. That's backwards.

ASL Vault inverts it: producers can only add. Reading requires a passphrase that never touches the automation plane — so the blast radius of a compromised writer is exactly zero secrets read.

What a stolen writer gets

  • The ability to add a new sealed secret
  • Metadata it was already allowed to see
  • Nothing it can decrypt from the store
  • No path to the master passphrase

The private key is never stored unwrapped; a wrong passphrase simply fails the GCM tag — there is no password hash to attack.

Capabilities

Cryptography doing the enforcing — not policy.

Write-while-sealed

A POST works while the vault is sealed and needs only the public key. This asymmetry is the whole product.

🔒

Sealed-box crypto

X25519 ECDH → HKDF-SHA256 → AES-256-GCM (libsodium-style crypto_box_seal) with zero external dependencies.

🗝

Key never stored unwrapped

The private key is protected with scrypt (N=2¹⁵) + AES-GCM; a wrong passphrase just fails the tag — no hash to crack.

Replay-binding salt

A replay-binding salt ties sealed writes to context, so a captured payload can't be silently re-submitted.

Unseal is memory-only

Unsealed state lives only in memory — a restart re-seals the vault. There is no unsealed-at-rest window.

Least-privilege tokens

Per-app SHA-256-hashed tokens with prefix grants (trailing * only, no regex) — enumeration-proof 404s hide what a token can't see.

Live-verified audit

An append-only hash-chained audit with verifyAudit() that re-checks integrity from genesis. Even the admin token can't decrypt secrets.

Metadata while sealed

Names and metadata stay readable while sealed for operations, while the values themselves stay locked.

🖥

Built-in GUI

A web console for reveal-one-at-a-time operation, with timing-safe compares and nosniff / no-store headers throughout.

~350 lineszero-dep Node on node:sqlite
ProtectSystem=strictNoNewPrivileges · PrivateTmp
LoadCredentialadmin token never on disk in the clear
node --testcovered end to end
The platform's secret backbone. Vault is the migration target for scattered secrets across the platform; its first consumer is the ASL AI Hub, whose provider credentials it holds. Escrowed keys can be decrypted offline with the master passphrase — the evidence survives the vendor.

Let the machines write. Only you read.

A credential store where a compromised writer leaks nothing, every reveal is logged, and the cryptography — not a policy toggle — does the enforcing.