lantern 0.1.0

lantern 0.1.0

First tagged release. lantern is a native, autonomous security assessment
agent for small Linux hosts: one binary, one SQLite file, no services to run.
The pipeline — plan → recon → check → verify → reflect — executes as host
processes on the machine you point it at, through a CLI.

What landed

Real exploitation capability

• Host tools behind the scope gate: host_nmap, host_nikto,
  host_tcpdump, host_sqlmap*, host_hydra*, host_nuclei*,
  host_msfconsole*, host_john* — those marked * only under --offensive.
• lantern setup provisions the machine in one command: distribution
  packages, john built from source (328 formats instead of the handful a
  package ships), nuclei with its template set, and the sandbox launcher.
  Metasploit is an opt-in repo. With no passwordless sudo it prints exactly
  what is missing rather than failing halfway through.
• lantern doctor reports device, budget, integrations and every tool path
  without touching the network.

A model that remembers, asks, and re-plans

• Two memory namespaces: per-engagement scope keyed exactly like the runtime's
  scope, and a global namespace for reusable guides — so a guide written once
  reaches every later engagement. Semantic recall through local embeddings,
  with an FTS5-only fallback that warns instead of pretending.
• ask_operator under --interactive: the model can ask the person running
  the assessment mid-flow, wait up to 300 s, then carry on unanswered. A stale
  environment variable can never make a silent run answer itself.
• The plan is shared state. Every role reads the current version at prompt
  time, the planner's ordered rewrite is adopted when it comes back as a real
  list, and plan_patch adds or drops a step once reconnaissance proves the
  plan wrong. The amended plan is what gets reported.

Search and compute

• web_search with mode: vulnerability: keyless NVD 2.0 keyword search
  merged ahead of the web results, relevance-filtered to the query tokens,
  sorted by CVSS, half the result budget.
• code_run for the coder: one Python script, standard library only, behind
  bwrap — empty network namespace, read-only filesystem, only the flow's own
  directory writable. Computation only; there is no way for it to reach a
  target. The script text is stored as an artifact; the binary and its entire
  argv are fixed in code.

Safety properties

• Never a shell: Command::new().args everywhere, argv arrays only, a binary
  allowlist, rlimits (CPU, AS, FSIZE, NOFILE, NPROC), a per-flow working
  directory, a timeout, an output cap, and every child audited to SQLite and
  JSONL.
• --offensive and the scope gate are checked before any active tool body
  runs; gating is derived from the registry, not a hand-kept list.
• API keys live in the environment and are never written to disk.
• Data root capped at 1.28 GB, logs at 200 MB, artifacts expire after 7 days,
  findings retained. The disk floor is never touched.

Verified on this build

• 158 tests pass, 1 ignored (the live NVD query), 0 warnings.
• Binary: 8,481,128 bytes (8.09 MB) — thin LTO, a single codegen unit, panic
  on abort, stripped.
• lantern doctor: exit 0 in 53 ms, 2 MB peak RSS, 12 native tools.
• The sandbox is asserted by the suite itself: no connection out, no write
  outside the flow directory, and rejected input never spawns anything.

Build and run

git clone https://github.com/ianclemence/lantern && cd lantern
cargo build --release              # ~/.cargo/bin/cargo if it is not on PATH
./target/release/lantern setup     # provision the host tools, once
./target/release/lantern doctor
export DEEPSEEK_API_KEY=...        # environment only, never on disk
./target/release/lantern run --target example.com --scope "example.com"

--dry-run walks the entire pipeline without a key or a single network call,
which is the fastest way to see what the report looks like.