Security Program
A rigorous, defense-in-depth approach to AI agent governance. Documented controls and transparent incident response.
Role-Owned Security
Security work is owned by the ISMS owner role. Detection is limited to Discord alerts from sigmashake-alerts, and triage is by hand with no 24/7 coverage.
Self-Contained Engine
The ssg engine is written in Go — a memory-safe language — and ships as a single self-contained binary. No runtime npm install and no node_modules tree on the user's machine, reducing install-time supply-chain exposure.
Local-First Evaluation
Rule evaluation runs locally by default. Optional, opt-in Jev assist (bring your own TypeSafe API key) sends the tool name and input to api.typesafe.ai and can turn an Allow into an Ask. Product telemetry is opt-in (disabled by default) and excludes file paths and tool input content.
Enterprise SSO & Isolation
SAML/OIDC IdP selector, custom RBAC, an opt-in per-org IP/CIDR allowlist, service accounts, and dedicated pool D1 databases for a small number of orgs. Orgs share the fleet D1 by default.
Cryptographic Integrity
SHA-256 content hash on every published ruleset (checked on install when a content hash is stored), Ed25519 signature check on every Hub pull; fleet bundles are signed with Ed25519 by the fleet service (client-side verification on load is not implemented in the Go ssg).
Edge-First Infrastructure
The web, API and compliance services run on Cloudflare Workers (V8 isolates, 300+ POPs). The desktop apps, the ssg CLI and daemon (on customer machines) and the Elixir streaming services run outside Workers. AES-256 at rest, TLS 1.3 only on the Worker hostnames, HSTS on the Workers that set it, Cloudflare WAF (managed ruleset), and Cloudflare-managed DDoS protection.
Defense in Depth
Twenty controls across identity, cryptography, data protection, application hardening, and data-subject rights — all self-assessed. Supporting evidence and the self-assessment evidence package are at the Trust Center (NDA for some items).
SAML + OIDC SSO
Interactive IdP selector. Okta, Google Workspace, and custom IdPs. SSO takes priority over ambient credentials.
Custom RBAC Roles
Org admins define fine-grained permission sets. Org-scoped fleet routes check the caller's role server-side through the per-request requireFleetRole middleware, which rejects a URL org that does not match the resolved tenant. Health, enrolment and agent-token routes do not use it.
IP Allowlists + Service Accounts
An opt-in per-org IP/CIDR allowlist in sigmashake-fleet gates requests pre-auth. It is off by default. It passes when the org has no rules. A break-glass bypass exists. Non-human service accounts with scoped API tokens for CI/CD.
Tenant Isolation Guard
Fleet routes that act on an org use a per-request role and org guard (requireFleetRole), which rejects a URL org that does not match the resolved tenant.
Ed25519 Bundle Signing (service side)
The fleet service signs fleet rule bundles with Ed25519. Client-side verification of that signature on load is not implemented in the Go ssg today: the daemon does not verify it, and the one-shot fallback does not merge or verify fleet sources. Tracked as planned work.
SHA-256 Content Hashes
Every published ruleset carries a content hash computed at publish time. When a content hash is stored, the CLI aborts install on mismatch. The CLI also refuses unsigned rulesets.
Local Audit Log
The local audit log is a SQLite audit_log table with a signature column that the shipped Go ssg leaves NULL. Per-row signing is planned. Rows are rotated at the row caps.
R2 Audit Archival
Audit batches are archived to R2 as NDJSON.gz with a deterministic, idempotent object key. A SHA-256 over the event-ID list is stored in the object metadata.
AES-256 at Rest
Cloudflare D1 and KV encrypt all stored data at rest. User records, sessions, rulesets, billing.
AES-GCM OAuth Tokens
GitHub OAuth tokens encrypted with AES-GCM and a 12-byte random IV before KV storage.
TLS 1.3 + HSTS
The Cloudflare edge accepts TLS 1.3 only on the Worker hostnames; TLS 1.2 and older are rejected (measured 2026-10-11). docs.sigmashake.com (Cloudflare Pages) also accepts TLS 1.2. The security, trust and compliance Workers send HSTS max-age=31536000; includeSubDomains with no preload token (live, checked 2026-10-15 with curl -sI). The accounts, sso, vault, secrets and promo Workers send a 2-year max-age with preload. sigmashake.com and docs.sigmashake.com send no HSTS header. No SigmaShake domain is on the HSTS preload list.
Database Isolation and Residency
Orgs share the fleet D1 by default. A small number of dedicated pool databases can be assigned to an org. No D1 location hint is configured and SigmaShake makes no data-residency commitment.
Edge TLS & Transport Hardening
This Worker sets HSTS (max-age 1 year, includeSubDomains, no preload) on every response. The Cloudflare edge accepts TLS 1.3 only on this hostname. This Worker also sets X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin, HSTS, and a Content-Security-Policy on every response. The CSP uses frame-ancestors 'none' and hash-pinned inline scripts. It still allows inline styles. This closes AI review SEC-2026-0618-01 (fixed in code 2026-10-11; HSTS is live, checked 2026-10-15 with curl -sI).
Injection Prevention
Values in D1 queries are bound as parameters; dynamic SQL clauses are built from fixed allow-lists.
WAF + DDoS + Turnstile
Cloudflare WAF (managed ruleset), automatic L3/L4/L7 DDoS mitigation, and Turnstile challenges on auth + contact paths.
Rate Limiting + ReDoS Guard
KV rate limits keyed on non-spoofable CF-Connecting-IP. The ssg rule engine uses a Thompson-NFA regex matcher with a ReDoS guard, so catastrophic backtracking cannot occur.
Self-Service DSR Intake
POST /api/v1/dsr accepts GDPR Art. 15–21 / UK GDPR / FADP / CCPA requests. Email is HMAC-hashed at intake — never stored in plaintext. 5/hr/IP rate limit; opaque token returned for status lookup.
Public Sub-Processor Feed
GET /api/v1/sub-processors.json publishes the Article 28(2) inventory as a machine-readable feed (id, name, url, category, data_access, purpose, data_categories, location). Customer DPA Annex III links here. 10-minute edge cache.
RoPA + TIA Automation
Monthly Article 30 Record of Processing Activities, derived from the canonical system-description.ts + vendor register — no duplicate inventory. A tia-snapshot collector tracks Transfer Impact Assessment (EDPB 01/2020) status per vendor. Transfer impact assessments are pending (none recorded yet). Google, Cerebras and jsDelivr also have DPA and transfer assessments pending.
Breach Notification Targets
72h to the supervisory authority under Art. 33; without undue delay to data subjects under Art. 34; affected customers receive notice within 72h of confirmation of a Personal Data breach, and the target is 36h where the customer is the controller (DPA section 9; see breach-notification-procedure section 7.1). The breach-notification-record collector checks the Art. 33 72h and Art. 34 notification timing recorded in the breach register. The customer-notice and 36h targets are procedure targets, not collector checks.
Content Integrity Verification
Every ruleset on the Hub is published with a SHA-256 content hash computed at publish time. When a content hash is stored, the CLI refuses to install the ruleset if the hash of the downloaded payload does not match exactly. The CLI also refuses to install an unsigned ruleset: it verifies the Ed25519 signature of the author on every install from the Hub.
Publish & Hash
Author submits ruleset. Hub computes SHA-256 over all rule bodies and stores it securely.
Secure Transport
Rulesets are served exclusively over Cloudflare-enforced strict HTTPS/TLS.
Local Verification
When a content hash is stored, the CLI independently hashes the received payload. If computed ≠ expected, installation aborts. The CLI also verifies the Ed25519 signature on every pull and refuses unsigned rulesets.
➜ sigmashake-mono git:(main) ✗ ssg hub pull <ruleset-id>
Fetching ruleset <ruleset-id>...
Example Ruleset v1 by @author — 11 rules
Verifying integrity... OK (sha256:45e18192c93b102b...)
Verifying Ed25519 signature... OK (signed by @author)
Installed: Example Ruleset v1
Integrity: sha256:45e18192c93b102b... VERIFIED
Technologies: example
Files written:
.sigmashake/rules/example.rules
Run 'ssg sync' to load the new rules into the evaluation engine.
Threat Model & Mitigations
| Attack Vector | Our Mitigation | Residual Risk |
|---|---|---|
| Database Compromise Attacker modifies rules in Cloudflare D1 |
Tampered hub rulesets produce a mismatched SHA-256 hash when a content hash is stored, and ssg hub pull rejects the installation. The CLI always verifies the Ed25519 signature on every hub install and refuses unsigned rulesets. The fleet service signs fleet bundles with Ed25519, but the Go ssg does not verify that signature on load today. |
Attacker also overwrites the hash column. Residual risk for fleet bundles: the fleet service signs them with Ed25519, but client-side verification on load is not implemented in the Go ssg (planned). |
| MITM / Interception Payload modified in transit |
TLS to the Cloudflare edge (TLS 1.3 only on the Worker hostnames) + local SHA-256 hash verification when a content hash is stored, and Ed25519 signature verification on every hub install (unsigned rulesets are refused). | Compromised Root CA. |
| Malicious / Weak Rules Rules designed to bypass safety |
Author identity is linked to GitHub OAuth. Hub prominently displays source repo and author handle. | Users must review third-party rules. No automated vetting (yet). |
| ReDoS Attacks Catastrophic regex backtracking |
The ssg rule engine uses a Thompson-NFA regex matcher with a ReDoS guard. It never backtracks, so catastrophic backtracking cannot occur. | Low: Thompson-NFA matcher; resource limits still apply. |
| Cross-Tenant Data Leakage One tenant accesses another's data or fleet rules |
Orgs share the fleet Cloudflare D1 by default; a small number of dedicated pool databases can be assigned. No D1 location hint is configured and no data-residency commitment is made. Fleet routes that act on an org use a per-request role and org guard (requireFleetRole), which rejects a URL org that does not match the resolved tenant. Health, enrolment and agent-token routes do not use it. | Platform-level Cloudflare isolation boundary. |
| Motivated Adversary with Shell Access Attacker intentionally crafts inputs to bypass rule matching |
Out of scope by design. SigmaShake is a guardrail for honest agents — preventing accidental harm from agents that are trying to do the right thing. It is not a sandbox and does not claim adversarial resistance. For this threat, compose with OS-level isolation (Docker with seccomp, Apple Sandbox, VM confinement). | Addressed by complementary OS sandboxing layer. |
| Rule Bypass via Encoding / Whitespace Obfuscated commands evade pattern matching |
Rules support layered operators (CONTAINS, REGEX, WORD, GLOB, LINE_REGEX) with priority ordering. High-priority deny rules can stack multiple condition groups. The DSL is a policy surface for honest agents, not an adversarial parser — for adversarial bypass resistance, pair with shell-level sandboxing. | Encoding-aware rules can be authored for known evasion patterns. Full adversarial resistance is out of scope. |
Security Roadmap
| Initiative | Description | Status |
|---|---|---|
| Ed25519 Signed Fleet Bundles | The fleet service signs fleet rule bundles with Ed25519. Client-side verification on load is not implemented in the Go ssg: the daemon does not verify the signature and the org public key comes from the server. Hub rulesets use a SHA-256 check on ssg hub pull when a content hash is stored, and the Ed25519 signature is always verified (unsigned rulesets are refused). |
Partial (signing only) |
| Local Audit Log Row Signing | Per-row signing of the local audit log. The shipped Go ssg writes the audit_log signature column as NULL and no code path fills it. Planned. | Planned |
| SIEM Log Forwarding | Fleet-side dual-mode stream-and-archive pipeline exports audit events to Splunk HEC, Cribl HTTP-in, Confluent Cloud Kafka REST, and generic HMAC-signed webhook sinks. Delivery uses a durable per-org buffer, then Cloudflare Queue delivery with exponential-backoff retry. | Shipped |
| SOC 2 Type II | SOC 2 self-assessment in progress (observation window 2026-05-18 → 2026-11-17); evidence is collected on daily, weekly, monthly and quarterly schedules. No CPA firm engaged; no engagement committed; no SOC 2 report or certificate exists. A Type II report is possible only after a CPA firm is engaged and completes its work (not before Q1 2027). Self-assessment evidence package available under NDA. | Self-assessed |
| ISO 27001:2022 | Statement of Applicability maps all 93 Annex A controls: 74 applicable, 15 inherited, 4 not applicable. 71 of the 74 applicable controls have current evidence (as of 2026-10-09). Self-assessed. 72 registered evidence collectors (as of 2026-10-09) dual-tag evidence with ISO control IDs. SoA live at compliance.sigmashake.com/compliance/iso27001. No external certification body engaged. | Self-Assessed |
| GDPR Control Family + DSR Pipeline | 31 GDPR articles catalogued (25 applicable across Ch. II–V, 6 documented not-applicable); 9 GDPR-specific collectors (DSR log, RoPA, sub-processor freshness, breach notification timing, privacy-notice currency, residency attestation, consent-config, TIA, DPIA register); 12 policy and analysis documents; public DSR intake + sub-processor JSON feed. No consent banner exists today (GA4 runs in Consent Mode v2, denied by default). Covers EU GDPR. No UK or Swiss transfer mechanism is recorded yet. Erasure and portability requests are handled by hand. 9 of the 25 tracked articles are partial (Art. 7, 15, 17, 20, 28, 32, 44, 45, 46). | Partial |
| AI-Assisted Internal Security Review — Compliance Worker (Claude Opus 4.7) · May 2026 (published 2026-05-13) | Code-level AI-assisted review of sigmashake-compliance — 3 defense-in-depth hardenings shipped: open-redirect normalisation in staff login, strict hex/charset validation on /api/v1/verify, public sub-processor feed minimisation. SQL injection, CSRF, SSRF, HMAC replay, and signing key flow reviewed clean. Note: AI-assisted internal security review (Claude Opus 4.7) — not a third-party penetration test. Relabelled 2026-10-14: the earlier 2026-05-19 date label is not evidenced; the exact test date is not recorded. | Shipped |
| AI-Assisted Internal Security Review — Security Worker (Claude Opus 4.8) · 2026-06-18 | White-box, code-level AI-assisted review of this Worker (security.sigmashake.com — public posture pages, /advisories disclosure + /advisories/manage, inline scripts, response headers, authoring APIs), conducted by Claude Opus 4.8 (Anthropic) with full source-code access, aligned to OWASP WSTG v4.2 and OWASP ASVS v4.0.3. Result: 1 finding — 1 low (0 critical, 0 high, 0 medium, 0 informational). SEC-2026-0618-01 (low): no security response headers (no CSP, X-Frame-Options, X-Content-Type-Options, or Referrer-Policy) on any route and no Hono header middleware, so the token-bearing /advisories/manage page is framable and its one-click resubscribe/unsubscribe POST actions are clickjackable; separately, the public posture card advertised a nonce-based-CSP / X-Frame-Options DENY / nosniff / strict-Referrer-Policy control this Worker does not actually ship. Bounded to the notification list — mutating authoring APIs are Bearer-gated and unaffected. Status: fixed in code 2026-10-11; HSTS is live (checked 2026-10-15 with curl -sI) (an earlier note said 2026-10-09; the live check on 2026-10-11 06:30Z showed no HSTS on this hostname). The Worker now sets X-Frame-Options DENY, nosniff, strict-origin-when-cross-origin, HSTS, and a Content-Security-Policy (frame-ancestors 'none', hash-pinned inline scripts) on every route. The posture card describes the shipped headers. The CSP still allows inline styles. Reviewed clean: SQL injection (parameterised D1), admin authorization (fail-closed, constant-time), XSS (escaped + scheme-restricted), token security (192-bit opaque, 24 random bytes as 48 hex characters, sent with no-store; shown only to the holder of the token link, never in error or not-found pages), open-redirect/SSRF (no user-controlled targets), CORS (wildcard only on read-only public feeds), subscriber enumeration (uniform response, double opt-in), input validation, ReDoS. Note: AI-assisted internal security review (Claude Opus 4.8) — not a third-party penetration test. Appended alongside the preserved Claude Opus 4.7 compliance Worker round (May 2026); does not replace it. | 1 Low: Fixed in code 2026-10-11 |
Compliance Frameworks
| Framework | Coverage | Status |
|---|---|---|
| ISO 27001:2022 Annex A | 93 controls across A.5 Organisational (37), A.6 People (8), A.7 Physical (14), A.8 Technological (34). 74 applicable, 15 inherited, 4 not applicable (A.6.1, A.6.2, A.6.4, A.6.6); 71 of the 74 applicable controls have evidence; A.5.3 is applicable with compensating controls. SOC 2 evidence is collected by cron-driven collectors on daily, weekly, monthly and quarterly schedules, with a daily Ed25519-signed manifest root. SoA, nonconformity register, internal audit record. | Self-Assessed |
| SOC 2 Type II | 43 Trust Services Criteria across CC, A, C, PI families. SOC 2 self-assessment in progress (observation window 2026-05-18 → 2026-11-17); evidence is collected on daily, weekly, monthly and quarterly schedules; a daily SHA-256 hash-chained evidence manifest root, Ed25519-signed and anchored into the hub transparency log on a best-effort basis (a hash chain, not a Merkle tree); the canary Worker folds an hourly Merkle root over its artifact manifest, stored unsigned until an operator signs it offline; Ed25519 signed audit packages exportable on demand. No CPA firm engaged; no engagement committed; no SOC 2 report or certificate exists. | Self-assessed |
| GDPR (EU 2016/679) | 31 articles catalogued across Chapters II–V — 25 applicable, 6 documented not-applicable. Self-service DSR intake at POST /api/v1/dsr (HMAC-hashed email, 5/hr/IP rate limit). Public Article 28(2) sub-processor JSON feed. Customer DPA template; the SCCs (2021/914, Module 2 or 3) are recorded only for Cloudflare. DPA and transfer assessment are pending for Google, Cerebras and jsDelivr. 9 GDPR-specific collectors: DSR log, RoPA (Art. 30), sub-processor freshness, breach notification timing (72h supervisory authority and data-subject timing; the 36h customer-controller target is a procedure target in breach-notification-procedure section 7.1, not a collector check), TIA status tracking (Schrems II; no TIA records exist yet), DPIA register (WP-248), privacy-notice currency, consent-config collector (no consent banner exists today), residency attestation. |
Self-Assessed |
| UK GDPR & Swiss FADP | No UK or Swiss transfer mechanism is recorded yet. A UK Addendum or IDTA and a Swiss addendum are targets only. UK ICO is the lead supervisory authority for UK transfers; FDPIC for Swiss. | Self-Assessed |
| CCPA / CPRA | No sale or share of personal information; right-to-know, right-to-delete, right-to-correct, non-discrimination; no cross-context behavioral advertising. | Self-Assessed |
| CIS Critical Security Controls v8.1 | 18 Controls (family-level): Inventory (CIS 1–2), Data Protection (CIS 3), Secure Config (CIS 4), Account & Access Management (CIS 5–6), Vulnerability Management (CIS 7), Audit Logging (CIS 8), Email & Web Protection (CIS 9), Malware Defense (CIS 10), Data Recovery (CIS 11), Network Infrastructure & Monitoring (CIS 12–13), Security Training (CIS 14, no formal training program; self-assessed), Service Providers (CIS 15), Application Security (CIS 16), Incident Response (CIS 17), Penetration Testing (CIS 18 — AI-assisted internal reviews, not third-party). Self-assessed alignment; no independent assessment. | Self-Assessed |
| NIST SP 800-53 Rev.5 | 20 control families (family-level): AC Access Control, AT Awareness & Training (no formal training program; self-assessed), AU Audit & Accountability, CA Assessment & Monitoring, CM Configuration Management, CP Contingency Planning, IA Identification & Authentication, IR Incident Response, MA Maintenance, MP Media Protection, PE Physical & Environmental (inherited from Cloudflare, per Cloudflare's own published documentation), PL Planning, PM Program Management, PS Personnel Security, PT PII Processing & Transparency, RA Risk Assessment, SA System Acquisition, SC System & Communications Protection, SI System & Information Integrity, SR Supply Chain Risk Management. Self-assessed alignment; not FedRAMP authorized; no independent third-party assessment. | Self-Assessed |
| HIPAA | Not applicable — SigmaShake does not process, store, or transmit Protected Health Information. | Not Applicable |
| PCI DSS | Delegated to Stripe (which states in its own published documentation that it is a PCI DSS Level 1 service provider). SigmaShake never processes cardholder data. Webhook signatures verified via HMAC-SHA256. | Delegated |
Full compliance evidence and the Statement of Applicability are available at trust.sigmashake.com. Staff-gated audit packages (ISO 27001 or SOC 2) can be exported on request.
Security Advisories
When a CVE or security event affects the ssg CLI, SigmaShake Fleet, or the platform, we publish a numbered advisory. Subscribers get an email when SigmaShake staff send the notice after publication. New SigmaShake accounts are enrolled in the advisory notification channel at signup (best effort) unless that email address has already unsubscribed; accounts created before enrolment began are not enrolled automatically, so subscribe on this page if you signed up earlier. Fleet and enterprise administrators are added at send time unless they have unsubscribed. Each recipient's minimum-severity setting applies.
Read past advisories, subscribe by email, or follow the machine-readable feeds:
- Advisory index — every published advisory
- RSS feed —
security.sigmashake.com/advisories.xml - JSON feed —
security.sigmashake.com/advisories.json
Responsible Disclosure
If you discover a security vulnerability in the Hub, the ssg CLI, or any SigmaShake service, please disclose it responsibly. We appreciate the work of the security community and will work closely with you to validate and resolve issues.
The full policy is at sigmashake.com/vulnerability-disclosure. This section is a summary.
Scope
- All websites under
*.sigmashake.com - The
ssgCLI binary - The
@sigmashake/ssgnpm package
Out of Scope
The following issues are considered out of scope:
- Vulnerabilities in third-party services (e.g., Cloudflare, Stripe, GitHub OAuth)
- Social engineering or phishing attacks against SigmaShake employees
- Denial of Service (DoS/DDoS) attacks
Reporting Process
Please submit vulnerability reports via email to security@sigmashake.com or use a report-formatting page that opens a pre-filled email to security@sigmashake.com.
Please include a detailed description of the issue, steps to reproduce it, and your assessment of its impact.
Response Timeline
We are committed to a timely response:
- Acknowledgment target: Within 72 hours of receipt.
- Triage: The on-call role confirms receipt and assigns a CVSS v3.1 severity.
- Remediation targets: Critical 72 hours, High 7 days, Medium 30 days, Low next planned release. These are targets, not guarantees.
Safe Harbor
SigmaShake considers activities conducted consistent with this policy to constitute "authorized" conduct. We will not initiate legal action against security researchers who report vulnerabilities in good faith and in compliance with this disclosure policy. If legal action is initiated by a third party against you, we will take steps to make it known that your actions were conducted in compliance with this policy.
Recognition
Security researchers who report valid, in-scope vulnerabilities will be credited in our resulting security advisories and release notes (opt-in).