> ## Documentation Index
> Fetch the complete documentation index at: https://authsome.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Daemon trust boundary

> What the loopback-only daemon model protects against, and what it doesn't.

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

| Threat                                     | Outcome                                                                                                         |
| ------------------------------------------ | --------------------------------------------------------------------------------------------------------------- |
| Network attackers on the LAN               | Cannot connect. The daemon binds to 127.0.0.1 only.                                                             |
| Internet attackers                         | Cannot connect.                                                                                                 |
| Unauthorized agents on the same host       | Cannot read credentials. Without the Ed25519 private key to sign the PoP token, the daemon rejects the request. |
| Tampering with an in-flight OAuth callback | Limited. The callback URL is `127.0.0.1:7998/auth/callback/oauth`. Only same-host traffic can reach it.         |

## What the boundary does not protect against

| Threat                                  | Outcome                                                                                                                            |
| --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| A process running as root               | Can read the `master.key` and the Vault directly. The daemon is not the bottleneck here.                                           |
| Memory inspection of the daemon process | Can read decrypted credentials held in active sessions or the proxy's request pipeline.                                            |
| Cross-session leak after a restart      | Active auth sessions are in-memory. A daemon crash mid-flow leaves orphaned state at the provider, but no credential leak locally. |

## 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

<Columns cols={2}>
  <Card title="Threat model" icon="shield-halved" href="/security/threat-model">
    The full asset list and trust boundaries.
  </Card>

  <Card title="The local daemon" icon="server" href="/concepts/the-daemon">
    What the daemon does and which routes it exposes.
  </Card>
</Columns>