Skip to main content
The Authsome daemon binds to 127.0.0.1:7998. It uses Proof-of-Possession (PoP) tokens to verify that callers belong to a registered Identity. This page explains what that boundary protects.

​
The model

Authsome assumes the local machine is generally trusted, but adds specific checks to isolate credentials:
  • The OS enforces loopback binding so only traffic from the same host reaches the daemon.
  • The daemon requires a PoP JWT signed by the agent’s cryptographic Identity (Ed25519 key) to authorize credential access.
  • That Identity must be bound to a Principal, which owns the Vault.

​
What the boundary protects against

​
What the boundary does not protect against

​
How to harden inside the boundary

You can reduce blast radius even further:
  • Run a per-user daemon by setting AUTHSOME_HOME to a user-specific path. This isolates Vault files across users on the same host.
  • Keep AUTHSOME_HOME off shared mounts unless you control every host that mounts it.
  • Watch the Admin Audit Dashboard (at /audit) or query authsome log for unexpected revoke, register, or export events.

​
What’s next

Threat model

The full asset list and trust boundaries.

The local daemon

What the daemon does and which routes it exposes.