This policy covers the code in this repository (PowerShell scripts, Bash scripts, docs). It does not cover:

• The Lightchain protocol itself or its smart contracts — disclose those to Lightchain directly (security@lightchain.ai if it exists, or via their Discord).
• The Lightchain worker Docker image (/bin/worker, /bin/lightchain-worker) — same, that's upstream code.
• Ollama, Docker, Foundry, or any other third-party dependency — go directly to the project.

• Vulnerabilities that cause the toolkit to leak the worker private key or password (e.g. printing it to logs, persisting it unencrypted, sending it over the network).
• Vulnerabilities that cause the toolkit to send funds to an unintended address (e.g. parsing bugs in the funder address validation, command injection in a script).
• Vulnerabilities that cause the toolkit to execute attacker-controlled code from a remote source (e.g. unverified Invoke-Expression).
• Privilege escalation in the toolkit's PowerShell ACL handling on Windows.

Anything that requires the attacker to already have file-system access to your secrets.{ps1,env} is out of scope — at that point they already have your keys.

Do not open a public GitHub issue for security reports.

Instead, email the maintainers at <REPLACE_WITH_REAL_EMAIL_AFTER_FORKING> with:

1. A clear description of the issue and its impact.
2. Steps to reproduce.
3. Suggested fix if you have one.
4. Your GitHub handle if you want public credit in the changelog.

You should get an acknowledgement within 72 hours. We aim to push a fix within 7 days of confirming a critical issue.

• We won't sue or threaten security researchers acting in good faith.
• We'll credit you publicly in the CHANGELOG unless you ask to remain anonymous.
• Please give us reasonable time to ship a fix before publicly disclosing.

See docs/security.md for the full threat model and recommended hardening. The short version:

• The WORKER_PRIVKEY is hot money — treat the worker wallet as a working balance, sweep rewards regularly to cold storage.
• The FUNDER_PRIVKEY should never sit in secrets.{ps1,env} long-term. Use a hardware wallet or session-only env var for the one-time funding tx.
• Run the worker on a dedicated machine if possible — same machine you browse the web from is a worse security posture.
• Full-disk encryption is non-negotiable on laptops.