Adapted from
docs/ARCHITECTURE.mdin lumen. See Lumen for the overview.
Lumen prioritizes predictable authority over integration count:
Lumen is not intended to protect a host from its OS administrator or from an already-compromised OS.
lumen-core is the only authority for policy decisions, approvals, capability grants, and action dispatch.Security kernel (lumen-core): identity and request context, agent-run orchestration, normalized action envelopes, capability/policy evaluation, approval lifecycle, executor dispatch, cancellation/budgets/deadlines, audit event construction. Acts as a reference monitor — every sensitive operation must be complete, non-bypassable, and mediated here.
Persistence (lumen-db): SQLite migrations, repositories, transactional persistence. Stores runtime state; makes no authorization decisions.
Integrations and executors (lumen-integrations): model-provider clients, plugin protocols, tool adapters, sandbox backends, external channel adapters. Translates between external protocols and core types. Not trusted to approve themselves or write authoritative audit history.
Third-party extensions run as either WASM components (portable, capability-oriented host API) or supervised subprocesses (MCP servers, native binaries, model runners — minimal env, resource limits, authenticated local channel, platform sandbox profile). Native dynamic libraries and in-process Rust plugins are not supported.
Untrusted: model output, plugin code, channel input, remote provider responses. Trusted: lumen-core policy decisions, runtime-emitted audit events, OS keychain secret storage.
Authenticated request → policy evaluation in lumen-core → approval (if required) → executor dispatch → sandboxed execution → runtime-emitted audit event. Every step is explainable after the fact.