Asset summary
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.