ASL Vault — Source library
Public documentation snapshot: 2026-09-08
Add keys while locked. Only you can open it.
A credential store you can add to while it is locked. Only your passphrase opens it.
Add keys while locked. Only you can open it.
Built for: The one person who ends up holding every key for a small company: API keys, app signing material, account recovery codes, backup passphrases · A small development or IT team where deploy scripts and setup jobs currently hold credentials that can read everything · An owner-operator who wants credentials on a machine they control, reachable only from that machine or through a door they put in front of it · Anyone who needs to answer 'who read that credential, and when' with a record instead of a guess
ASL Vault exists because of this.
Open your Downloads folder and count. There is probably a signing password in a text file from the last app release, a recovery code someone pasted into a chat two years ago, an API key inside a config file on a laptop that is not backed up, and a spreadsheet somebody started when the first three got confusing. You know roughly where everything is. You could not prove it to anyone, and you could not say which copy is the current one. The quieter half of the problem is worse. Loading credentials into a store is usually the moment they are most exposed: the store has to be open to accept them, so whatever is doing the loading is working inside an unlocked vault, and anything watching that process sees an unlocked vault too. The same is true every time you add one more key. A store that has to be opened to be filled turns routine housekeeping into a recurring moment of risk, which is exactly why people keep putting it off and leaving the keys where they already are. And when something does go wrong, the question you get asked is the one you cannot answer: which credential was read, by what, on what day. A folder of files cannot tell you. Neither can a chat thread or a shared note. You are left saying 'probably nobody' and hoping that holds up. Rotation has the same shape — you replace a key, you think you replaced it everywhere, and nothing anywhere records whether you did.
ASL Vault exists because of this.
Filling it is not the same as opening it. A new credential goes in while the vault stays locked, so the routine act of loading and rotating keys never puts the existing ones on the table.
ASL Vault exists because of this.
There is no recovery service, and that is stated on the way in rather than discovered on the way out. Nobody at ASL can reset your passphrase or read your entries, so nobody at ASL can be tricked, subpoenaed, or breached into doing it.
ASL Vault exists because of this.
Applications read and never write. An earlier version allowed any registered application to overwrite any stored value; that was found in an internal review in August 2026 and closed the same day, and the finding is published here rather than buried.
ASL Vault exists because of this.
Nothing is readable by default, and a permission can only ever be a whole name or a name prefix — never a pattern that quietly matches everything.
ASL Vault exists because of this.
The history is verified from its first entry every time it is displayed, so a deleted or edited row shows up as a break instead of a record that still looks tidy.
ASL Vault exists because of this.
The phone app has no network permission at all. It is not a promise about what the app does with a connection; it is the absence of one.
ASL Vault exists because of this.
The credential service pulls in no outside packages at runtime, so its supply chain is what you can read rather than a dependency tree you inherit.
How ASL Vault works, start to finish.
ASL Vault is a credential store built around one deliberate split: the key material that locks a value away and the key material that opens it are two different things, and only one of them is ever needed to put something in. Adding a new credential, or replacing an old one, works while the vault is locked. Reading a value requires your passphrase, which is never stored anywhere and is unlocked only into memory for as long as you keep the vault open. So loading the vault is never a moment of exposure: you can file forty credentials into a locked vault and nothing in that process is ever able to read one back — not the person doing it, not the job doing it, not anything watching it. Writing is reserved for the owner's credential, deliberately. An earlier version let any registered application write, which meant a single compromised application could quietly overwrite a more important credential with a value of its choosing; that was found in an August 2026 review and closed the same day. Today applications read, they never write. Anything you hand the owner credential to can file and rotate entries while the vault stays locked and still cannot decrypt a single one — but it can also delete entries, so treat that credential as the powerful thing it is. Day to day you work from an inventory that stays readable while the vault is locked: every entry's name, category, description, who filed it, when it was created and when it was last replaced. You can audit what you are holding, hand a colleague a list, and confirm a rotation happened without ever unlocking anything. Values themselves are shown one at a time, on request, only while the vault is open, and every single reveal is written to the history. On the phone app a revealed value hides itself again after thirty seconds and the screen cannot be captured while it is showing. Applications get their own credential and read only the entries they were granted. A permission is granted by name or by name prefix, so when you rotate a key the application that depends on it keeps working without you re-granting anything, and nothing is readable by default. Asking for a value that was never granted returns exactly the same answer as asking for one that does not exist, so a stolen application credential cannot be used to discover which values it might be able to open. Be clear-eyed about the limit of that: the inventory itself — names, categories, descriptions and dates — is visible to any application you have registered, and the fact that the vault exists, whether it is locked, and how many entries it holds are visible to anything that can reach it at all. Grants control what can be opened, not what can be seen listed. The history is append-only and chained, so it is tamper-evident rather than merely long. Every add, replacement, reveal, deletion, lock, unlock, failed unlock attempt, application registration and permission change goes in. The chain is re-checked from the very first entry each time you look at it, so a row that was edited or quietly deleted is reported as a break instead of being accepted as normal. Values never appear in the history — only the fact that access happened, by whom, and when. The service answers only on the machine it runs on. Reaching it from anywhere else is something you add in front of it — a private connection you open, or a sign-in gate, which is how this company reaches its own. Because every value is individually sealed, a copy of the store is safe to keep somewhere else: the values in a copy are exactly as unreadable as the values in the original, and neither opens without your passphrase. There is also a separate phone vault for people who want the same discipline in a pocket. It has no network permission at all — not a promise not to upload, but no ability to connect — no account, no telemetry, and no reset service. It seals itself the moment you leave the app, exports an encrypted backup through your phone's own file picker, and checks a backup's entire history before it will replace what you have.
Everything in the current release.
Each of these is built and working today. Nothing on this list is a roadmap item.
Add to it while it stays locked
Filing a new credential, or replacing one, does not require the vault to be open. The write path uses only the half of the key material that can lock a value away and can never open one, so loading the vault is not a moment when its contents are exposed. This is the whole design, not a setting you can accidentally turn off.
Only your passphrase opens it
The key that reads values is never stored in usable form. It is unlocked with your passphrase, held in memory only, and discarded when you lock the vault or the machine restarts. There is deliberately no remember-me, no stored password hint, and no second way in. A wrong passphrase simply fails, and the attempt is recorded.
Reveal one value, on purpose
Values are never listed in bulk and there is no page that dumps them. You ask for one, you get one, and the request is recorded with the name, the actor and the time. On the phone the revealed text hides itself after thirty seconds, the screen cannot be captured while it is showing, and leaving the app clears it and re-locks the vault.
Per-application read permission
Each application that needs a credential gets its own token and reads only the entries it was explicitly granted. Grants match a whole name or a name prefix, so rotating a key does not break the grant and does not require you to re-authorize anything. Nothing is readable by default, and a grant can only ever end in a prefix wildcard, never a pattern that could surprise you by matching everything.
Ungranted and non-existent look identical
A request for a value an application was not granted returns exactly the same response as a request for one that does not exist, so a stolen application token cannot be used to work out which values it might be able to open. This applies to opening values. The inventory listing is a separate thing and is visible to any registered application, so keep secrets out of names and descriptions.
A history that shows tampering
Every add, replacement, reveal, deletion, lock, unlock, failed unlock, application registration and permission change is written to an append-only record where each entry is bound to the one before it. The whole chain is re-verified from the first entry each time you open it, so an edited or removed row is reported as a break instead of passing quietly. Values themselves never appear in the record.
Rotate without breaking anything
Replacing a credential keeps the same name, the same permissions, and the same place in your inventory, and stamps the entry with the date it was rotated. Applications that read it keep working. The old value is replaced, not shadowed by a second copy nobody remembers to clean up, and the replacement is recorded as a rotation rather than a new entry.
Inventory you can read while locked
Names, categories, descriptions, who filed each entry, and the created and rotated dates all stay readable with the vault shut. You can run an audit, prove a rotation happened, or hand someone a list of what exists without opening a single value. Only the value field is sealed — which is exactly why nothing secret should ever go in the other fields.
Answers only on the machine it runs on
The service listens on its own machine and nowhere else. Anything beyond that — a private connection you open to it, or a sign-in gate in front of it — is a door you add and control. This company runs its own instance behind a company sign-in for exactly that reason. Nothing about your credentials is shipped to a service you do not run.
Copies you can keep elsewhere
Because every value is sealed individually, the values in a copy of the store are exactly as unreadable as the values in the original. That makes off-machine copies practical: you can keep one on another drive or in another location without creating a second thing that has to be defended. The inventory in a copy is as readable as the inventory in the original, so the same rule applies — no secrets in names or descriptions.
A phone vault with no network at all
The phone app requests no internet, storage, contacts, camera, microphone, advertising, or telemetry permission — the list is empty, not short. It has no account, no cloud sync, and no connection to the desktop vault. It is for the recovery codes and passphrases you want with you and nowhere else, and it cannot transmit them because it has no way to.
Encrypted backup you carry yourself
On the phone you export an encrypted backup through the system file picker to a destination you choose; the file contains your sealed entries, their metadata and their history, but never your passphrase. Importing one validates the file's structure, every sealed entry and its complete history before it will replace anything, and it makes you type the word REPLACE first.
Built-in guide that works offline
The phone app ships a plain-language guide covering what is protected, what is only metadata, what an export does and does not contain, what deleting really means, what the app cannot defend against, and a short safe operating routine. It works with every radio switched off, which is exactly when you are most likely to need it.
Honest about deletion
Deleting an entry removes it and records the deletion — on the phone you have to type the entry's full name to confirm — and the product says plainly that this is not forensic erasure. Storage hardware, earlier exports, and backups made outside the app can retain remnants. You are told that instead of being sold a guarantee nobody can keep.
Numbers we can stand behind.
Every figure below comes from the product's own release record or test suite, not from a marketing estimate.
Numbers we can stand behind.
This is the store this company's own keys live in — 51 credentials as of 13 August 2026, every one filed while the vault was locked.
Numbers we can stand behind.
Inventory stays usable while the vault is shut, so routine work — auditing, proving a rotation, handing someone a list — does not require opening anything.
Surfaces and status.
Status as of 2026-09-02. Running since 1 August 2026 as the credential store this company's own platform depends on, holding 51 credentials as of 13 August 2026 — every one filed while the vault was locked — with nightly encrypted-at-rest copies that are opened and checked against the live store before they are kept (internal operations record, 13 August 2026). The sign-in-protected console answered over a secure connection on 2 September 2026, and the credential service's 13 automated checks were re-run and passed on the same day. It is labelled Internal rather than Live because there is no customer instance, no self-serve sign-up and no published price: the only running vault is this company's own. The phone app is signed at 1.0.3 (build 4) and passed a full two-device acceptance run on 23 August 2026, but its store listing has not been created, so it cannot be bought either.
Worth more together.
Products on this platform share one sign-in, one support queue, and one engineering standard. These pair naturally with ASL Vault.
ASL AI Hub
AI Hub is the intended first consumer: its credential lookup was deliberately built behind one narrow interface so it can point at the vault instead of at credential files. That switch has not been made yet — it is the next step on the roadmap, not a finished integration.
ASL Files
Encrypted storage and a sealed credential store solve two halves of the same job — the archive lives in Files, the recovery key that opens it lives in the vault, and neither one is useful to a thief on its own.
Aegis
The vault is only as private as the machine it runs on. Aegis watches that machine for intrusion and tells you when something changes, without locking you out of your own server.
ASL Command Center
If you run more than one thing, Command Center is the single console for health and approvals across all of it — useful once credentials, backups, and services stop living in one person's memory.
What does it cost?
There is no published price list for the credential service today, and no hosted instance to subscribe to; getting it running on a machine you own is a setup conversation, so ask for a quote. The phone app is prepared as a single USD 9.99 purchase with no subscription and no in-app purchases, but its store listing has not been created yet, so it cannot be bought right now.
We already use a password manager. Why would we add this?
A password manager is built for a human typing a password into a login box. This is built for the credentials your machines and releases depend on — API keys, signing material, backup passphrases, recovery codes — and its central idea is that putting one in never requires opening the rest. If the awkward part of your current setup is that loading or rotating a key means unlocking everything, that is the gap this closes; if it is not, you may not need this.
What happens if I lose the passphrase?
The values are unrecoverable. There is no reset, no backup key held by ASL, and no support process that can get them back, because the ability to open your vault genuinely does not exist outside your passphrase. Write it down, keep it somewhere physical and separate from any backup copy, and confirm you can unlock before you rely on the vault for anything critical.
What can an application actually see?
It can open only the values you granted it, by whole name or by name prefix, and asking for anything else returns the same answer as asking for something that does not exist. It can, however, list the inventory — the names, categories, descriptions and dates of everything you hold — so treat those fields as public within your own systems and never put a secret in them. Anything that can reach the service at all can also see whether it exists, whether it is locked, and how many entries it holds.
What happens to our credentials if we stop paying, or if ASL disappears?
Nothing stops working. The vault runs on your machine and does not check in with anyone, so there is no licence server to go dark and no account to be suspended. Your copies stay readable with your passphrase, and the phone app, once installed, works indefinitely with no network at all.
Is it actually ready, or is this something you are still building?
It is finished software in daily production use — but ours, not yet anyone else's. It has run since 1 August 2026 as the store this company's own keys live in, 51 of them as of 13 August 2026, with nightly copies that are opened and verified rather than assumed. There is no customer instance and no self-serve signup today, so putting one on your machine is a setup engagement. The phone app is finished, signed, and passed a full acceptance run on two devices, but its store listing has not been created, so it is not installable yet.
How do we move what we already have into it?
You file entries in with the owner credential, one at a time or in a batch, and the vault takes them while it stays locked — loading it never means opening it. The practical work is deciding what actually is a credential: store the recovery key for an encrypted archive, not the archive; store the whole credential file's contents rather than picking one password out of it, because the surrounding notes are what you need during a real recovery. Deduplicate first, because the same key tends to be copied into every release folder you have ever made.
How safe is a backup copy of the vault?
The values in a copy are exactly as unreadable as the values in the original, because each one is individually sealed rather than protected by the surrounding storage. That is what makes off-machine copies practical instead of frightening. Two caveats: the inventory in a copy is as readable as the inventory in the original, so no secrets in names or descriptions; and it still opens only with your passphrase, so keep the passphrase somewhere the copy is not.
Can more than one person use it, and can I see who read what?
Reads by applications are individually permissioned: each application gets its own credential and reads only the entries it was granted, by name or name prefix. Human access is a single passphrase today — there are no per-person logins inside the vault — so a two-person team shares one passphrase or runs two vaults. Every reveal, every unlock, and every failed unlock attempt is recorded, and the record is checked for tampering each time it is displayed.
Has it been independently audited?
Not by an outside firm, and we will not claim otherwise. The reviews behind it were run by the team that built it. One in August 2026 found that any registered application token could overwrite a stored value; writing was restricted to the owner's credential the same day. The automated checks covering wrong-passphrase rejection, tamper detection, cross-vault rejection and least-privilege permissions all pass, and were re-run on 2 September 2026.
What should I know before I rely on it?
We would rather you hear this from us than discover it later. As of 2026-09-02:
What should I know before I rely on it?
If you lose the passphrase, the values are gone. Nobody at ASL can reset it or recover them. That is the design, and it is the single thing you must plan around before you put anything important in.
What should I know before I rely on it?
Filing a value requires the owner's credential. An automation you hand that credential to can add and rotate entries while the vault stays locked and still cannot decrypt one — but it can also delete entries. A scoped write permission, letting an application write only the names it was granted, is a deliberate future change and is not built today.
What should I know before I rely on it?
Any application you register can list the whole inventory — names, categories, descriptions and dates — even though it can only open the values it was granted. Anything that can reach the service at all can see whether a vault exists, whether it is locked, and how many entries it holds, with no credential whatsoever. Permissions control what can be opened, not what can be seen listed.
What should I know before I rely on it?
Names, categories and descriptions are readable while the vault is locked, by design, so the inventory works. Never put a secret in those fields; only the value field is sealed. The same is true inside any copy of the store.
What should I know before I rely on it?
There is no lockout after repeated wrong passphrase attempts. Every attempt is recorded and each one is deliberately slow to compute, which makes guessing expensive rather than impossible — so choose a long passphrase, not a short complicated one.
What should I know before I rely on it?
The console is this company's own instance and requires a company sign-in. There is no self-serve signup that hands you a hosted vault; running one for you is a setup conversation, not a checkout button.
What should I know before I rely on it?
As of the last dated record, 13 August 2026, no other product had yet been switched over to read from it. The per-application read path is built and covered by automated checks, but it is not yet carrying daily traffic.
What should I know before I rely on it?
The phone app is finished and signed but its store listing has not been created, so you cannot buy or install it today. The prepared price is USD 9.99 as a one-time purchase, and a limited pre-release round is planned before any public paid release.
What should I know before I rely on it?
The phone app and the desktop vault do not sync, talk to each other, or share entries. They are two separate vaults on purpose, and moving something between them means exporting or re-entering it yourself.
What should I know before I rely on it?
The phone app's protections — the auto-hiding reveal, the blocked screenshot, the automatic re-lock — assume the phone itself is not already compromised. Its own built-in guide says so plainly: a compromised device, a hostile accessibility service or keyboard, a root process, or a person looking over your shoulder are outside what any app can defend against.
Add keys while locked. Only you can open it.
Prefer email? contact@autosecurelogin.com