Helix Threat Model (concise)

Purpose: keep determinism, provenance, and user data trustworthy even when plugins or inputs are untrusted.

Assets

Artifact and bundle integrity (hash-matched files, manifests, reports).
Deterministic execution guarantees (reproducible runs across machines/backends).
Policy/profile enforcement, including taint + trust classification.
Plugin trust store and registry metadata.
User inputs and project data (sequences, configs, snapshots); support bundles must respect redaction rules.

Malicious plugin publisher: ships a .helixplugin intended to exfiltrate data or break determinism.
Poisoned input provider: supplies hostile configs/artifacts to flip policy gates or trick verifiers.
Supply-chain attacker: tampers with dependencies, build outputs, or release distribution channels.
Local unprivileged user: attempts to read/write another user’s bundles or trust store on the same host.
Operator error / misconfiguration: weak policies or running in debug mode without realizing the downgrade.

Plugin host: in-process today; planned extension-host isolation. Enforced trust store + optional signature gates.
Runtime/backends: deterministic seeds + fixed schedulers; backends declare D0/D1 determinism class.
Artifacts/bundles: manifest hashes are the integrity boundary; verifiers refuse mismatches.
Build + release: source → build → packaged artifact → signed hashes; verified offline via docs/policies/release_provenance.md.

Plugin loading/updates, registry consumption, and trust store handling.
Artifact/bundle verification, schema validation, and deterministic replay (CLI + Studio headless).
Build/signing pipeline and distribution of installers/zips and canonical conformance packs.
Policy/profile enforcement and taint propagation into reports and exports.

Host OS/firmware compromises, GPU driver/kernel bugs, or physical access attacks.
Arbitrary Python execution when the user bypasses the plugin system or runs ad-hoc scripts.
Pure availability/DoS without trust or safety impact.
Third-party forks or unsigned, repackaged installers.

Reproducible plugin packages: sorted zip entries, fixed timestamps, HASHES.json checked at install; optional Ed25519 signatures checked against a trust store.
Dependency integrity: pinned versions; wheels are validated against expected hashes during release builds when available.
Release channel: SBOM + SHA256SUMS + signatures; planned build attestations (SLSA-style) tying source, builder, inputs, and outputs.
Registry hygiene: registries served over HTTPS; expected sha256 may be provided per entry; offline install supported from local packages.

Every run emits a run_id and taint class; verifiers fail closed on manifest/hash mismatches.
Plugin diagnostics/logs include publisher id and hash; Studio surfaces trust level in the plugin manager.
Security issues follow the disclosure/patch process in SECURITY.md.