Skip to content

Safety and Trust Boundaries

JanYork edited this page Aug 14, 2026 · 1 revision

Safety and Trust Boundaries

Language: English · 简体中文

LWC is local-first, not data-free. Its safety model separates canonical knowledge, derived indexes, deployment configuration, external tools, and Agent hosts into explicit trust boundaries. Security and privacy depend on correct scope, filesystem ownership, minimal stored content, and bounded integration surfaces.

Data inventory

Potentially sensitive durable data includes:

  • complete Source snapshots and observed origin paths;
  • Page bodies, titles, summaries, citations, provenance, and links;
  • Purpose, Schema, tags, strong-context policies, and operation history;
  • recorded search wording and --reason text;
  • retrieval weights and feedback metadata;
  • checkpoints and sparse draft databases;
  • generated Markdown;
  • CodeGraph symbol names and project file paths;
  • Agent integration receipts and owned host fragments.

Document-graph sidecars, FTS tables, spans, Viewer responses, and Hook context are derived copies or views of this authorized state. Their being derived does not make them non-sensitive.

Data locality

LWC core storage, search, graph engines, Viewer, and MCP run locally. Grafeo and SurrealDB are embedded. Viewer uses embedded assets and binds to loopback.

CodeGraph runtime is downloaded from the pinned GitHub Release when explicitly initialized, then runs locally with telemetry disabled. Optional MarkItDown and AnyDoc execute as local subprocesses under their own upstream behavior; review those tools before converting sensitive documents.

Agent hosts and their model providers remain separate trust boundaries. LWC cannot control what an Agent sends to its configured model after reading a Page or Hook context.

Secret scanning

Selected Source and configuration inputs are rejected when they look like:

  • a non-template .env file;
  • a private-key filename or .key, .p12, .pfx credential file;
  • PEM, OpenSSH, or PGP private-key markers;
  • known credential prefixes such as AWS, GitHub, OpenAI, or Slack tokens;
  • explicit conversion credential flags.

This scanner intentionally favors obvious, high-risk patterns. It is not a data-loss-prevention system and cannot recognize every customer secret, password, private URL, session token, or proprietary fact.

Review inputs before ingest. Do not weaken the scanner to accept one real secret.

Minimize durable content

Do not store:

  • raw hidden chain-of-thought or private model reasoning;
  • transient build logs and large debug dumps;
  • credentials, cookies, access tokens, private keys, or passwords;
  • customer data outside the project's authorized classification;
  • unsupported guesses presented as facts;
  • sensitive query wording in --reason or optional recorded search.

Store concise verified conclusions, source citations, and the smallest evidence needed for future work.

Query privacy

search, lint, Viewer, and MCP are read-only by default. Search wording enters the operation log only with explicit recording.

Retrieval feedback stores the SHA-256 fingerprint of normalized query terms rather than raw query text, but its reason is durable. A fingerprint reduces accidental disclosure; it is not encryption and may still be correlatable for a known query.

Strong-tag Hook context intentionally loads full selected Pages. Keep autoload tags small and do not classify secret material as session-wide rules.

Filesystem and path controls

LWC validates project containment and rejects unsafe symlinks for Store, config, draft runtime, Work, checkpoint, graph, materialization, conversion, and CodeGraph paths.

Owned state files use restricted permissions where supported and atomic replacement or create-new semantics. lwc init can add .lwc to the repository's local Git exclude; verify repository policy instead of committing runtime state.

Local filesystem permissions remain the primary confidentiality boundary. Backups, checkpoints, temp directories, and crash reports must receive the same protection as wiki.db.

MCP boundary

The Agent-facing server exposes one read-only tool, lwc_explore:

  • every call supplies an absolute project path;
  • filesystem root and relative paths are rejected;
  • modes and limits are validated;
  • missing graph capabilities remain unavailable rather than being initialized;
  • write-shaped additional properties are rejected by the tool schema;
  • CodeGraph and memory reads stay inside the selected project.

MCP transport security outside local stdio belongs to the host. LWC does not expose a network MCP listener.

Hook and Instruction boundary

Lifecycle Hooks return bounded readiness, strong-tag context, and timing guidance. They do not execute graph initialization or conversion setup.

Instruction injection is marker-bounded and additive. A target adapter owns only its named MCP entry, Skill directory, recognizable Hook/plugin entry, and marked Instructions. Receipt hashes prevent refresh or uninstall from silently overwriting later user edits.

Host trust prompts, UI permissions, and preview activation remain user-managed unless an official narrow file surface exists.

Viewer boundary

Viewer:

  • listens on 127.0.0.1 only;
  • exposes GET/HEAD routes;
  • has no authentication and must not be publicly proxied;
  • sanitizes Markdown and forbids active embeds;
  • applies Content Security Policy, frame-ancestors 'none', and nosniff;
  • does not initialize or mutate indexes.

Other same-host processes may reach the port. Stop Viewer after use on shared systems.

Conversion boundary

LWC validates project-contained input/output by default, uses create-new Markdown output, enforces timeout and size bounds, and passes only the configured adapter arguments after a final safety check.

Conversion does not automatically ingest output. Review it for prompt injection, malicious links, unexpected omissions, and secret exposure before adding it as a Source.

External input requires an explicit option. That option expands source location, not output ownership or adapter argument authority.

Backups and deletion

Deleting a Page or Source through CLI does not erase copies already present in checkpoints, old draft databases, filesystem backups, Agent transcripts, or remote repository history.

Define retention separately for:

  • named checkpoints;
  • failed or abandoned drafts;
  • generated Markdown backups;
  • CodeGraph indexes;
  • Agent host logs and conversations;
  • system backups.

Do not promise cryptographic erasure from a logical delete.

Vulnerability reporting

Do not open a public issue containing a working exploit, secret, private repository path, or user data. Use the repository's Security policy and include:

  • affected version and platform;
  • trust boundary crossed;
  • minimum non-sensitive reproduction;
  • whether canonical data, credentials, or host files changed;
  • safe cleanup or containment steps;
  • proposed embargo needs.

Security acceptance

Before enabling an integration or importing sensitive evidence, confirm:

  1. selected scope and project path are correct;
  2. data classification permits local and Agent/model access;
  3. no secret appears in content, arguments, reasons, or logs;
  4. optional upstream tool behavior is acceptable;
  5. filesystem and backup permissions are sufficient;
  6. Hook/tag context is bounded;
  7. uninstall or recovery will not destroy foreign data.

Next: Release and upgrade operations

LWC Wiki

English · 简体中文


Start here · 开始使用

Core capabilities · 核心能力

Practical guides · 实战指南

Capability configuration · 能力配置

Technical design · 技术设计

Operations · 运行与维护

Reference · 参考资料

Contributing · 参与贡献


Repository · Releases

Clone this wiki locally