ASL Vault is an internal credential-storage tool that accepts additions while locked. Review passphrase access, recovery limitations and integration scope.
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.
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
The problem
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.
What changes
What it does
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.
Features
Each of these is built and working today. Nothing on this list is a roadmap item.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The native phone app has no network access and requests no access to shared storage, contacts, camera, or microphone. It contains no advertising or telemetry SDK. Android may declare an internal signature-only receiver permission; this is not a request to access your information. 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.
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. Import checks the file format, key and sealed-envelope structure, and local audit hash chain before replacement, and requires typing REPLACE. A value's cryptographic authentication is checked when you reveal it; import is not an independent signature or provenance check.
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.
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.
Proof
Every figure below comes from the product's own release record or test suite, not from a marketing estimate.
Where it runs
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 because it is the vault this company runs for itself; installing one for you is a setup engagement rather than a checkout.
The phone app is signed at 1.0.3 (build 4) and passed a full two-device acceptance run on 23 August 2026, and it is supplied direct from us while its store listing is prepared.
Works with
Products on this platform share one sign-in, one support queue, and one engineering standard. These pair naturally with ASL Vault.
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.
Explore →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.
Explore →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.
Explore →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.
Explore →Questions buyers ask
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, and it is supplied direct from us while its store listing is prepared.
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.
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.
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.
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.
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. It is installed for you as a setup engagement rather than through self-serve signup. The older phone build1.0.3 had a dated acceptance run in August2026. Native candidate1.0.4 is now undergoing final release review; it is not being advertised as a publicly available Play release.
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.
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.
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.
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.
We would rather you hear this from us than discover it later. As of 2026-09-02:
A credential store you can add to while it is locked. Only your passphrase opens it.
Prefer email? contact@autosecurelogin.com
Offline Android / 20 September 2026
The native Kotlin app is separate from our server Vault. There is no account, sync service, notification registration, hosted recovery, or background network connection.
Candidate1.0.4/code5 uses atomic file replacement and rejects oversized writes before replacing the current document. It retains the v1 encrypted-backup format. Limits are1000 records,10000 audit entries, and10 MiB. Existing values can still be read and exported if the audit reaches capacity; a warning explains when new audit events cannot be recorded. History is not silently trimmed.
Values are sealed while locked. Candidate1.0.4 protects sensitive dialogs, clears temporary key buffers on error paths, and seals when the activity pauses, including configuration recreation. Screen capture protection is a precaution, not a defense against a compromised phone, hostile keyboard or accessibility service, or a physical observer.
The candidate passed15 unique JVM checks in both configurations and10 Android16 emulator regressions. Its signed upgrade retained a fictional record created by1.0.3 and decrypted it with the original test passphrase. Pixel8 testing of this version and a fresh Google Play status check are still outstanding. Current Play availability is not asserted here.
Metadata is readable while sealed. The local hash chain checks consistency; it is not a signed, independently anchored, or tamper-proof audit. Someone able to replace a vault file can rewrite the chain or remove its tail. Keep trusted backups. Losing the passphrase can make an exported backup unusable; ASL cannot reset it.
A backup leaves the app only through a file destination you explicitly select. A cloud document provider may upload it according to that provider's rules. Deleting the app record does not erase prior exports or guarantee forensic erasure.
Auto Secure Login