Security

Lobu is built for multi-user agents: each user or channel gets an isolated worker, while secrets and outbound policy stay on the gateway. A compromised worker should not see raw credentials or reach arbitrary networks.

Core Model

Per-session workers — each conversation runs in its own subprocess spawned by the gateway. Workspaces and state do not cross sessions; the subprocess can be SIGKILL’d cleanly without taking the gateway down.
Gateway is the control plane — all outbound HTTP, credential resolution, tool policy, and MCP calls route through it.
Workers never see real secrets — provider credentials are replaced with opaque placeholder tokens; the gateway’s secret proxy swaps them back before forwarding to upstream APIs.

Network Isolation

Workers route all outbound HTTP through the gateway’s in-process proxy on 127.0.0.1:8118 (HTTP_PROXY=http://localhost:8118). On Linux production hosts the worker spawn is wrapped in systemd-run --user --scope with IPAddressDeny=any + IPAddressAllow=127.0.0.1, which enforces the egress block at the kernel; on macOS dev hosts HTTP_PROXY is advisory at the language layer.

Domain access is controlled by env vars:

Variable	Behavior
`WORKER_ALLOWED_DOMAINS`	unset/empty → no access (default). `*` → unrestricted. Otherwise a comma-separated allowlist.
`WORKER_DISALLOWED_DOMAINS`	Blocklist, applied when `WORKER_ALLOWED_DOMAINS=*`.

Domain format: exact (api.example.com) or wildcard (.example.com matches all subdomains).

LLM-judged egress

For domains where flat allow/deny is too coarse, like Slack, GitHub user-content, or Notion, skills can route requests through an LLM judge that decides per request. Only domains that match a judge rule invoke it, so the cost stays bounded. Skills declare judged domains and named policies in SKILL.md; operators layer an extraPolicy on top in lobu.config.ts.

See Egress judge for the policy schema, judge defaults (Haiku, verdict cache, fail-closed circuit breaker), and the egress-decision audit record.

Credentials

Workers never receive raw provider credentials or OAuth tokens. The gateway resolves credentials, injects them only at proxy time, and keeps workers on opaque placeholders or agent-scoped proxy URLs. See Secret proxy for how the lobu_secret_<uuid> placeholder swap works at egress.

Category	How it works	Where secret material can live
Provider secrets	Standalone `lobu run` can read from `.env` / `$ENV_VAR` or `secret_ref`. Embedded mode can pass `key` / `secretRef` at startup or resolve credentials dynamically per request.	Built-in Postgres-backed encrypted secret store, external refs such as `secret://...` or `aws-sm://...`, or a host-provided embedded secret store
Per-user MCP / OAuth tokens	Collected through device-auth and injected by the gateway MCP proxy per call. Integration auth for GitHub, Google, Linear, and similar services is handled through Lobu.	Writable gateway secret store or host-provided embedded secret store

AWS Secrets Manager refs are read-only. aws-sm://... works well for durable provider secret references, but refreshed user tokens still need a writable secret store.
Workers never touch third-party OAuth tokens directly. They call integrations through Lobu MCP tools and the gateway proxy.

For concrete config examples, see the lobu.config.ts reference and the CLI reference.

MCP Proxy