Principles

Things Sandworm will never do.

Ten commitments, each with a date. These are not aspirations or marketing promises — they are decisions we have already made and built into the product. We publish them so procurement and security teams can verify them rather than negotiate them.

Reviewed annually. Last review: 2026-05-21. Items added or removed are tracked in the git history of this page.

1. We will never sell per-event pricing.

Per-event billing forces customers to ration logs. Rationed logs mean the AI sees less, and what the AI does not see, it cannot detect. Sandworm prices on a flat, tier-based model so coverage is never a budget conversation. Sovereign tier customers ingest every byte they generate. There is no per-event tier on the roadmap.

2. We will never sell or share your threat intel data.

IoCs derived from your environment belong to you. We will never resell them, syndicate them to a threat-intel marketplace, or share them with another customer. Move 6 federation produces a differentially-private aggregate that is mathematically incapable of identifying which tenant contributed which observation; that is the only cross-customer exchange that happens.

3. We will never train our AI on your logs without per-tenant attestation.

Mendicant AI (the Sandworm-trained security LLM) trains only on data that has a signed per-tenant attestation explicitly authorizing the training corpus. The attestation is verifiable at the public trust portal. If you have not signed the corpus attestation, your data is not in the training set. Period. The default for every tenant is no-training.

4. We will never enable destructive auto-response actions by default.

block_ip and isolate_host are high blast-radius. Move 17 flipped notify_slack, revoke_session, and quarantine_user to default-on because they are recoverable in seconds. block_ip and isolate_host stay default-off for every tenant, on every tier, indefinitely. Tenants who want them must opt in explicitly per action, and the operator opt-out is preserved through every migration.

5. We will never silently change a feature flag default.

Every flag default change ships in a named release with a 24-hour pre-deploy notice in the customer trust portal and an explicit entry in the dated commit log. We never flip a tenant's production posture without telling them first. This applies even to flags whose new default is more conservative.

6. We will never sunset a paid feature with less than 18 months notice.

Once a feature is in a paid tier it stays in that tier for at least 18 months after the deprecation announcement. If we replace it with a successor, we run them in parallel for that full window. Procurement teams can plan multi-year budgets on a single page; we will not turn a renewal into a forced upgrade conversation.

7. We will never require you to write a detection rule from scratch.

Every detection-bearing product (Truthsayer, Sandworm SASE, CloudGuard, Sandworm EDR) ships with a curated baseline rule set covering the industry profile you select at onboarding. Move 22 detection preview lets you tune the existing rules with live histogram + sample feedback. You can always author your own rules, but the platform never depends on you doing so.

8. We will never store customer secrets in plaintext.

Move 4 introduced pluggable secrets backends (Postgres-envelope, HashiCorp Vault, customer-KMS). Every secret at rest is encrypted with a tenant-scoped key, and the customer-KMS option means we never see the plaintext at all. There is no operator override, no break-glass plaintext store, no fallback path. If we cannot decrypt your secret with your key, we cannot use it.

9. We will never use closed-source-only output formats.

Findings, attestations, and exports use OCSF (Open Cybersecurity Schema Framework) and JSON-LD where applicable. The sandworm-ocsf package is open source. You can export everything you generated through Sandworm and re-ingest it into a different tool. Vendor lock-in by data format is a deliberate non-choice.

10. We will never cherry-pick which attestations we publish.

The public trust portal at /trust indexes every attestation Sandworm signs. We do not curate which ones appear, and we do not retract published attestations after the fact (errata are appended, not redacted). Move 20 makes every claim independently verifiable; cherry-picking would defeat the verifiability that is the trust portal's only purpose.

Why publish this?

Private commitments disappear at the next renewal, the next acquisition, or the next personnel change. A public page is a different kind of commitment: it is visible to every customer, every reporter, and every prospective hire. The cost of breaking a public commitment is higher than the cost of breaking a contractual clause that nobody reads.

The attestations that back each commitment are independently verifiable at /trust.