Security
Know exactly where your keys and data go.
When you evaluate AI models with your own provider accounts, security should not depend on vague promises. EidoStack is designed around clear security boundaries so you can understand where credentials live, what leaves the browser, and what the application stores.
01 / Security model
Provider credentials and workspace data are intentionally separate.
Your API keys belong to the browser-side vault. Your chats, folders, messages, and usage records belong to the EidoStack workspace. The two are intentionally different.
Master Password
Entered and used in the browser.
Key Derivation
Browser derives vault cryptographic keys.
Encrypted Provider Keys
Ciphertext is persisted in browser storage.
Unlock Vault
Credentials become available in browser memory.
Direct Provider Request
Browser authenticates to the selected AI provider.
The EidoStack application database does not store your OpenAI, Anthropic, or Google AI API key values. That boundary is the foundation of the security model.
02 / API Key Vault
Your API keys are encrypted before they are stored.
When you add an API key in Settings / Providers, EidoStack encrypts it in your browser before writing the encrypted record to browser storage.
Provider credentials stay inside the browser vault.
The active vault supports OpenAI, Anthropic, and Google AI credentials. Stored records contain ciphertext and encryption metadata rather than readable provider keys.
Provider keys are encrypted before browser persistence.
Each supported provider value is encrypted independently.
The encrypted provider record is scoped to the signed-in EidoStack account in that browser profile.
The plaintext provider key is not persisted as an EidoStack database value.
Vault Unlocked
Provider keys are available in memory.
Your master password does not leave the browser.
The vault master password is separate from your EidoStack account password. It is used in the browser to derive cryptographic material. The EidoStack API supplies an account-specific vault salt, but the master password itself is not sent to the API.
Recovery has a hard boundary.
EidoStack cannot recover a forgotten vault master password. Resetting your EidoStack account password does not decrypt the vault. Without a usable encrypted backup, the local vault must be reset and provider credentials added again.
Read the API key vault documentation →03 / Provider requests
Provider access is used where the request happens.
After the vault is unlocked, the selected provider key is decrypted into browser memory and used by the browser to authenticate requests to the selected AI provider.
Request origin
Your Browser
The workspace prepares the request and uses the unlocked provider credential.
Destination
AI Provider
The selected provider receives the content required to generate the response.
Provider credentials stay out of the EidoStack application server.
For supported model requests, the browser sends requests directly to the approved host used by the selected provider. Provider-key-bearing requests are guarded against unrelated destinations.
Your prompt still goes to the AI provider.
Depending on the evaluation configuration, the provider can receive your prompt, system instructions, selected conversation history, and other included context. The provider processes that data under its own terms and may charge your provider account.
04 / Data boundaries
Not all EidoStack data lives in the same place.
Provider credentials and evaluation workspace data serve different purposes, so the architecture treats them as different categories.
Browser-local
Browser Vault
Provider access stays local. The application database does not store your provider API key value.
Server-side workspace
EidoStack Workspace
Workspace data is persisted for later evaluation, organization, and analysis. It is separate from the local provider-key vault.
Separating these categories lets EidoStack preserve the evaluation workspace without turning the application server into a provider-credential store.
05 / Lock & Remember Me
A locked vault changes what the application can access.
The encrypted vault is useful only if locking it changes what the application can access. Encryption at rest and runtime state are separate parts of the boundary.
Locked
- The encrypted provider-key record can remain stored locally.
- Decrypted provider credentials are unavailable to the provider-key runtime.
- Model requests cannot use the stored provider credentials until the vault is unlocked.
Unlocked
- The encrypted provider-key record remains locally persisted.
- Provider credentials are decrypted into browser memory.
- Provider requests can use those credentials during the active session.
When the vault is locked or the active account changes, runtime provider values are cleared. Encryption at rest does not remove the need for a plaintext credential in browser memory while the browser is actively authenticating a provider request.
Remember Me is a convenience trade-off.
Remember Me does not store the master password. Instead, the browser stores cryptographic material that lets the vault encryption key be recovered on that device without asking for the master password on every new unlock.
Trust the device accordingly.
A device that can automatically reopen the vault keeps more local recovery material. Use Remember Me on devices you control. On shared, public, or temporary machines, leave it disabled and lock the vault when you finish.
06 / Backup and recovery
Recovery is explicit rather than automatic.
Because the active provider-key record is local, moving to another browser does not automatically restore provider credentials from EidoStack servers. Recovery uses an explicit encrypted vault backup.
Current Browser
Unlocked Vault
Encrypted Backup File
New Browser
Backup Password
New Local Vault
The backup password is separate from the vault master password.
An unlocked vault can create an encrypted JSON backup containing configured provider credentials. During restore, the backup is decrypted with its backup password and the recovered credentials are encrypted into the target browser under a new master password.
A vault backup is not a workspace backup.
It contains provider access only, not chats, folders, messages, prompt history, or usage history. Keep the backup file and its password protected because possession of both may allow the stored credentials to be restored.
Read backup and restore documentation →07 / Provider control
Your provider account remains the ultimate authority.
EidoStack stores credentials that grant access to provider accounts, but it does not control those accounts. Provider credentials should always be retired at their source.
Revoke or rotate at the provider.
If an API key may have been exposed, revoke or rotate it in the provider account first, then replace the value in the local EidoStack vault. The provider controls whether the underlying credential remains valid.
Local deletion is different from provider revocation.
Resetting the EidoStack vault removes the encrypted credential from that browser, but does not invalidate the original provider key. Deleting an EidoStack account can remove workspace data, but does not revoke credentials issued by another provider.
Read account data controls →08 / Security limits
Security should include the limits.
The vault protects provider credentials at rest and keeps them outside the normal application-server storage path. It does not turn a browser into a trusted hardware security module.
What the design protects
Provider values are encrypted before browser persistence.
The vault master password is not sent to the EidoStack API.
A locked vault keeps decrypted provider credentials unavailable to the provider-key runtime.
Provider-key-bearing requests are restricted to approved hosts.
What it cannot protect
A provider key must exist in browser memory while it is actively used.
A compromised browser, malicious extension, injected script, or local device may observe unlocked runtime state.
Remember Me leaves additional cryptographic recovery material on the trusted device.
The selected AI provider still receives request content you choose to send.
The precise claim
EidoStack uses encrypted local provider-key persistence with a client-held master password and direct browser-to-provider requests. It does not claim that provider keys are never plaintext anywhere, and it does not claim that EidoStack can recover provider credentials from its servers.
09 / Cryptography
Cryptography under the hood.
The active vault implementation uses browser Web Crypto APIs and concrete cryptographic primitives rather than relying on a generic claim that credentials are secure.
Derivation
PBKDF2
Processes the master password and account-specific salt in the browser.
Hash
SHA-256
Used by the vault password-based key-derivation process.
Encryption
AES-GCM 256
Encrypts provider values before local persistence.
Nonce handling
Fresh IV per field
Each non-empty provider field receives a fresh 12-byte initialization vector.
10 / Credential lifecycle
Control the lifecycle of your provider credentials.
Security is not only about encryption. A credential moves through creation, local persistence, active use, locking, backup, rotation, and reset.
Create
Encrypt
Store
Unlock
Use
Lock
Back up / Rotate / Reset
You decide when to create the vault, when to unlock it, whether the browser should remember the unlock, when to lock it again, when to create an encrypted backup, and when to reset local provider access. The provider remains responsible for issuing and revoking the underlying credential.
Common Questions
Does EidoStack store my provider API keys on its application server?
Does my master password go to EidoStack?
Are API keys ever decrypted?
Does EidoStack send prompts to AI providers?
Can EidoStack recover my vault password?
Can I move my provider keys to another browser?
Does deleting my EidoStack account revoke provider API keys?
Is the vault a replacement for device security?
Security by design
Know the boundary. Keep control of the credentials.
EidoStack separates provider access from workspace data, encrypts provider credentials before local persistence, keeps the master password in the browser, and makes the data path explicit enough to inspect.