Asset summary
| Asset | Where it lives | At-rest protection |
|---|---|---|
| OAuth access/refresh tokens | Vault (encrypted SQLite) | AES-256-GCM (Argon2id DEK) |
| API keys & Client secrets | Vault | AES-256-GCM |
OAuth client_id | Vault | Plaintext |
| Provider definitions | Filesystem | None (not sensitive) |
| Master key | ~/.authsome/server/master.key or OS keyring | Filesystem permissions or keyring |
| Identity keys | ~/.authsome/identities/<handle>.key | Filesystem permissions |
| Audit log | SQLite (daemon-managed) | None (intentionally queryable) |
| In-flight auth sessions | Daemon memory | Process boundary |
What Authsome protects against
Credential sprawl. Tokens and API keys live in one encrypted store rather than as plaintext environment variables scattered across every project’s.env, shell config, or CI secret store.
Secrets in process listings. authsome run injects credentials at the HTTP proxy layer. The child process never sees the real secret, preventing leaks through ps, /proc/<pid>/environ, or subprocess environment inheritance.
Secrets in shell history. Tokens and API keys are never accepted as command-line arguments. They are collected through a local browser bridge or masked terminal input.
Offline disk access. AES-256-GCM protects against a stolen disk image or another user reading your home directory. An attacker cannot decrypt records without the master key, which lives separately.
Stale tokens. OAuth refresh is automatic. Agents get a fresh token at runtime and never need to handle expiry. There is no long-lived embedded token sitting in a script to leak.
Cross-tenant contamination. Vaults belong strictly to a single Principal. Credentials owned by one Principal are invisible and inaccessible to Identities claimed by another Principal.
What Authsome does not protect against
A compromised root process. If an attacker has root access on the machine, they can read the master key and the Vault directly. Authsome is a local broker, not a sandbox. Memory inspection. Resolved credentials are held in the daemon’s memory and briefly in the proxy’s request pipeline. A process withptrace or kernel access can read them.
Malicious provider definitions. Custom providers in ~/.authsome/providers/ can declare any api_url. Authsome validates the schema, not the intent. Only register definitions you trust.
Network attackers on the wire. Authsome relies on TLS to the provider. The mitmproxy CA it installs is limited to the local machine for outbound interception. Authsome does not validate certificate transparency or pin provider certificates.
Trust boundaries
| Boundary | What’s inside is trusted | What’s outside is not |
|---|---|---|
| Network | The daemon at 127.0.0.1:7998. | Anything else on the LAN or internet. |
| Identity | An agent holding a valid Ed25519 key. | Any caller without a valid PoP token. |
| Local machine | The user’s account and processes running under it. | Other user accounts on the same machine. |