Local security

10.1 Baseline

Listening only on localhost is not absolute security: a malicious web page can still try to reach local ports. LMSP therefore combines several measures.

• A service MUST bind to the loopback addresses by default. It MUST NOT listen on 0.0.0.0, or on any other non-loopback address, unless LAN mode is enabled (section 10.5).
• On first run, a service SHOULD generate a high-entropy random service secret, and use it, rather than any built-in default, to issue and verify tokens.
• Every request to the core interface MUST carry a valid bearer token, except for the bootstrap endpoints listed in section 4.2. Coming from loopback is never enough on its own.

10.2 Pairing and tokens

A client gets its own bearer token with a local pairing code. The user asks the service to show a pairing code, in whatever way the service offers, and the client submits it:

POST /lmsp/v1/pair
Content-Type: application/json

{
  "client_name": "example-client",
  "pairing_code": "K7QD-4M2X",
  "scopes": ["inference"]
}

The service answers with a token. The token_type is always Bearer:

{
  "client_id": "cli_01J8MAT3W6X9B2D5F8H1K4N7QZ",
  "access_token": "lmsp_example_3f9a1c52e7d84b60",
  "token_type": "Bearer",
  "scopes": ["inference"]
}

The client then sends Authorization: Bearer <token> with every request.

• A pairing code MUST be single-use and SHOULD expire within 5 minutes. It SHOULD carry at least 40 bits of entropy. A service MUST rate-limit failed attempts. A wrong or expired code is answered with 401 and unauthorized.
• Tokens are independent per client, so the user can revoke one client without affecting the others. A service SHOULD let the user list and revoke paired clients.
• A client SHOULD keep its token in the operating system keychain or credential manager. A service SHOULD store only a hash of each token.
• A missing, invalid or revoked token is answered with 401, unauthorized and a WWW-Authenticate: Bearer header. A valid token that lacks the scope an endpoint needs is answered with 403 and forbidden.

10.3 Scopes

Permissions are split into separate scopes. Downloading models, deleting models and executing tools never ride on the inference scope.

Tasks and stored responses belong to the client that created them. A service SHOULD answer a request from another client as if they did not exist (task_not_found or response_not_found).

10.4 Browser and network protections

• A service MUST reject cross-origin browser requests by default, and allow only Origin values that are explicitly configured. A request with any other Origin is answered with 403 and forbidden.
• When an origin is allowed, the service answers its CORS preflight requests and sends Access-Control-Allow-Origin with that exact origin, never with *.
• A service MUST validate the Host header, to prevent DNS rebinding. It accepts only host names it serves: the loopback names and addresses, plus any names configured for LAN mode. Any other value is answered with 403 and forbidden.

10.5 LAN mode

LAN mode means listening beyond the loopback addresses.

• A service MUST NOT enable LAN mode unless the user explicitly turns it on.
• In LAN mode a service MUST require authentication, and SHOULD also enable TLS. A client SHOULD NOT send a token over plain HTTP to a non-loopback address unless the user explicitly allows it.
• mDNS advertisement is allowed only in LAN mode, when the user has also turned on LAN discovery (section 3.2).

10.6 Logging and privacy

• Model paths, logs, prompts and generated content MUST NOT appear in mDNS advertisements.
• By default, a service SHOULD log metadata only (times, endpoints, status codes, ids, token counts and durations). It SHOULD NOT log full prompts or generated content.
• Health responses and error details MUST NOT contain model paths, prompts, access tokens or other sensitive information.