Skip to main content

Configuration

Two files. Both hot-reload: save, and the running agent picks the change up within about two seconds. An invalid edit is rejected and the previous version stays live.

/etc/lumen/agent.yaml — where things live​

agent:
  listen: "127.0.0.1:7645"          # or "unix:/run/lumen/agent.sock"
  policy: /etc/lumen/policy.yaml
  spool: /var/lib/lumen/spool.db    # durable queue, survives restarts
  findings: /var/lib/lumen/findings.jsonl
  # intel: /var/lib/lumen/intel.bloom   # threat-intel snapshot
  reload_interval: 2s
policy: is load-bearing

It is the only thing that makes /etc/lumen/policy.yaml get read. Leave it unset — commented out, or an explicit policy: "" — and the agent runs the policy compiled into the binary instead, which enforces (pr_injection blocks). The daemon logs a WARN on startup when it falls back, and lumen-agent policy effective always says which one is live.

A proxy: section makes run serve the capturing proxy alongside the inspection API — one engine, one policy store, one findings file. The two listeners need separate addresses because they share a process.

/etc/lumen/policy.yaml — what to do about what​

A packaged fresh install ships this file in monitor mode: every rule's action is log. Promoting a rule is a one-word change:

- id: pr_secrets
  detector: sensitive_data
  subclasses: [credentials, financial, pii]
  applies_to: [prompt, response]
  action: log          # <- change to `redact` to start stripping secrets

The full grammar — access rules, thresholds, custom definitions, precedence — is in Policy model.

Check before trusting​

lumen-agent policy validate --policy /etc/lumen/policy.yaml
# policy pol_packaged_monitor v1 valid (bundle sha256 a5df05047d01)

lumen-agent policy effective --config /etc/lumen/agent.yaml
# policy source: /etc/lumen/policy.yaml
# policy id:     pol_packaged_monitor   version 1   sha256 993496456bd5
# mode:          MONITOR - every detector runs and nothing is redacted or blocked

Upgrades never overwrite your edited config files — which is exactly why a hand-edited agent.yaml that dropped the policy: key keeps enforcing the embedded policy across upgrades until someone reads the warning.