Local runtime
Local runtime security model
Aarmos listeners bind to loopback by default. Any broader network exposure requires explicit operator intent and a configured network-authentication mode.
The security boundary of the local runtime is not its port number. It is where the listener binds and who is allowed to talk to it. Port 7681 is a convention and can be changed at any time with --port.
Exposure classes
Every listener records an exposure class alongside its address, because an address alone is not useful to an auditor. Classification is semantic: ::1 is loopback, :: is the wildcard.
- loopback — 127.0.0.0/8, ::1, localhost. The default, and the only class enabled today.
- local-ipc — Unix domain socket or Windows named pipe, isolated by filesystem permissions.
- network — 0.0.0.0, ::, and any routable address. Refused.
Why network exposure is refused rather than confirmed
The moment a governance runtime accepts remote clients, the threat model stops being local IPC and becomes a network service: it needs authentication, authorization, TLS identity, replay protection, rate limiting, and key lifecycle. A confirmation prompt is not a substitute for any of those. Until a network-authentication mode exists, a non-loopback listen address returns an error and records a refused bind event.
Transport is pluggable. Authentication is mandatory.
Aarmos supports more than one local transport, and the security model does not depend on which one you use. Loopback TCP is the default because it is what proxy environment variables, third-party agents and arbitrary SDKs already speak. A Unix domain socket or Windows named pipe is preferred where the client is first-party, because the operating system removes the network surface entirely.
Every local connection is authenticated the same way on both, with a session credential minted when the listener starts and revoked when it stops. One authentication model, one audit model, one session lifecycle, one revocation path — on every platform, and on whatever transports come later.
Local transport is an implementation detail. Every local connection is authenticated. The operating system provides the first security boundary; Aarmos provides the second.
The two answer different questions. The OS access control answers can this process connect? The session credential answers is this an authorized client of this runtime session? They are complementary, and neither is redundant.
The credential is bounded in time as well as in scope: it expires 12 hours after it is minted (24 hours maximum, shortenable), and an expired credential is refused even in compatibility mode. A token recovered from a stale session file, a backup, or a copied dotfile does not authenticate.
| A remote host on the same LAN reaches your runtime | Listeners bind to loopback. Traffic from another host is never accepted. |
|---|---|
| A drive-by request from a public network | There is no routable listener to reach. Remote access is absent, not merely disabled. |
| An operator accidentally exposes the runtime | A non-loopback --listen value is refused outright. No confirmation flag overrides it. |
| A second OS user on a shared machine | Loopback is per-host, not per-user, so this depends on the local client authentication option below — see the honest limits. |
| Silent change to how the runtime was exposed | Every listener start and every refused bind is recorded as a hash-chained runtime lifecycle event, with the exposure class, not just the address. |
| Another process running as the same OS user | It can connect to the loopback port, and it can read any credential file your user can read. A local token does not change this. Treat same-user code as inside the boundary. |
|---|---|
| Malware with root or administrator rights | It can read process memory, keys, and evidence before signing. No local runtime defends against this. |
| A compromised agent you chose to govern | Aarmos governs the calls the agent makes through it. It records what the agent attempted; it does not verify the agent's intent. |
| Traffic that never routes through Aarmos | Egress observed through the proxy or an adapter is governed. Calls made outside those paths are not seen. Coverage is stated per connector, never as total. |
| TLS payload inspection | Hostname-only proxying by design. Aarmos does not decrypt HTTPS. Rich evidence comes from adapters, not interception. |
The same-user limit, stated plainly
A credential file readable only by your user does not defend against another process already running as your user — that process can read the file too. Local client authentication is useful against accidental misuse, cross-tool confusion, other OS users on a shared host, and containers that do not share your home directory. It is not a sandbox. We will not describe it as one.
Check your own posture
aarmos doctor prints the live binding, exposure class, authentication mode, and whether the recorded bind-event chain is intact. That output is the artifact to attach to a security review.
Related: shared responsibility · trust