Where this file is silent, the Simtabi security policy applies.

The preferred channel is GitHub private vulnerability reporting: open a private report at https://github.com/sangehq/authama/security/advisories/new. The report stays attached to the repository, with a draft advisory and a CVE request path. Email security@simtabi.com if you do not use GitHub.

Do not open a public issue for a security report.

Include, where possible: a description of the issue, affected version(s), reproduction steps, and any suggested remediation. We aim to acknowledge reports within a few business days and will keep you updated on remediation progress.

Authentication Access Manager (authama) manages SSH private keys and config, and the auth-token files package managers and git read. A few invariants are security-load-bearing - please flag any regression in these:

• Secrets never touch git. Private keys live in ~/.ssh; the config home (~/.config/authama) holds .env and age-identity.txt, and the state home (~/.local/state/authama) holds *.age bundles, log/audit.log, and snapshots/. authama refuses to load a .env that other users can read. All live outside any repository; in the project checkout the equivalent paths are also gitignored, and a gitleaks CI job scanning the full history is the safety net.
• Key passphrases. When you generate passphrase-protected keys, the passphrase reaches ssh-keygen through the askpass protocol (authama acts as its own askpass helper) and on stdin, never on its command line, so it does not show in ps//proc. Only the empty passphrase of an unprotected key is passed as -N "".
• Provider tokens at rest. A provider token_env (e.g. GH_TOKEN) in the home .env is plaintext at mode 0600. To keep it out of plaintext, set the value to cmd:<command> and the token is fetched at use-time from any secret manager (it never touches disk): GH_TOKEN="cmd:op read op://Private/GitHub/token", or "cmd:keyring get authama gh_token", or "cmd:age -d -i <id> token.age".
• Permissions are enforced. Directories 700, private keys + config 600, .pub + known_hosts 644 - set on create and re-asserted by doctor.
• Per-profile isolation. An identity's keys and config live under ~/.ssh/profiles/<profile>/, and every host renders IdentitiesOnly yes, so a host is only ever offered the keys of its own profile. Trusted host keys are kept in one hashed store, ~/.ssh/known_hosts, shared by every profile (see authama ssh knownhosts).
• The encrypted bundle never contains .env (it holds the age recipient refs that unlock the bundle).
• Token files are owner-only and written atomically. auth.json, .npmrc, Docker's config.json, .git-credentials and .netrc are written to a temp file at 0600 and renamed into place; doctor warns on a looser mode (doctor --strict and token audit fail on it) and doctor --fix tightens it.
• The token config holds no secrets. It names environment variables; the values are read at run time and written only to the tools' own files.
• Secrets are not printed or recorded. token list masks them unless --reveal is confirmed, token copy copies without printing, token apply does not echo COMPOSER_AUTH, and the audit log and history record the target and host, never the value. The web UI never receives or shows a token.
• No credential injection. .npmrc, .netrc and the git credential store have no quoting, so a newline or whitespace in a value could add a second credential. Such values, and malformed hosts, are refused before any write.
• Docker credential stores are respected. A registry Docker keeps in a credential helper is logged in with docker login --password-stdin (the token on stdin, never argv) or refused; a non-interactive run with no setting refuses.
• Dev mode cannot reach real credentials. Under --dev-root every token file maps into the sandbox, the tools' path variables are ignored, and docker login is refused.

This project is pre-1.0; security fixes land on main and the latest release.