Threat Model

SigmaShake is a guardrail for honest agents — not a sandbox for adversarial ones. Understanding this distinction helps you deploy it correctly and avoid gaps.

What SigmaShake defends

The engine is designed to prevent harm from agents that are trying to do the right thing but lack complete knowledge of your constraints:

• An agent makes a destructive command because it wasn't told your production directory is out of scope.
• A misconfigured automation writes secrets to a public path because the rule wasn't set up yet.
• A junior dev's agent runs npm install --save on a package that doesn't match your pin policy.
• An agent calls a write API when the user only authorized a read operation.

These are the 95% case. They're not attacks — they're policy enforcement failures. SigmaShake closes them at the tool-call boundary, before any action executes.

What SigmaShake does NOT defend

A motivated adversary with local shell access is out of scope.

If an attacker can already run arbitrary code on the machine where ssg is installed, they can bypass the hook by calling the underlying tool directly. SigmaShake is a Claude Code hook, not a kernel-level sandbox. Circumventing a hook requires intent — it doesn't happen by accident.

For adversarial confinement, use OS-level isolation alongside SigmaShake:

Threat	Right tool
Motivated attacker bypassing rules	Docker + seccomp, Apple Sandbox, VM confinement
Agent escape from malicious tool output	Sandboxed execution environment
Prompt injection from untrusted content	LLM output filters (Lakera, Guardrails AI, etc.)
Accidental destructive agent actions	SigmaShake

These tools are complementary, not competing. A well-defended AI agent stack uses all of them.

Rule bypass via encoding or whitespace

Rules use layered operators: CONTAINS, REGEX, WORD, GLOB, LINE_REGEX, and more. High-priority rules can stack multiple condition groups.

An honest agent doesn't try to bypass rules — so encoding tricks, Unicode substitution, and whitespace obfuscation are not realistic attack vectors for the threat model SigmaShake addresses. If you're writing rules to catch adversarial evasion, you're using the wrong tool; you need a sandbox.

That said, you can write encoding-aware rules for known patterns using REGEX with case-insensitive flags.

Supply chain: the Hub

Every ruleset downloaded from the Hub is:

1. Content-hashed at publish time — modification breaks the hash check.
2. Ed25519-signed in the Hub manifest — ssg hub pull verifies the manifest envelope and the per-ruleset signature. The CLI does not verify Fleet policy bundle signatures today.
3. Reviewable as plain DSL before install — open the ruleset page on hub.sigmashake.com/ruleset/<ruleset-id> to read it. After ssg hub pull, the installed .rules files in .sigmashake/rules/ are plain text that you can read too.

You are never required to trust a ruleset you haven't reviewed.

Summary

Attack	In scope?	Mitigation
Accidental destructive agent action	✓ Yes	Rules block/ask/redirect at hook
Policy misconfiguration	✓ Yes	Rule linting + audit log
DB-compromise / MITM on Hub download	✓ Yes	Ed25519 + content hash
Cross-tenant data access	Partial	Orgs share the fleet D1 by default; a small pool of dedicated databases can be assigned. Tenant isolation guard; the tenant-isolation evidence check covers identifier columns only
SIEM log egress to a private/internal host (SSRF)	✓ Yes	HTTPS-only + private-IP block + port allowlist + redirect:'manual'; re-validated at delivery time (see Fleet SIEM)
Credential theft from SIEM destination config	✓ Yes	AES-GCM envelope encryption at rest; plaintext never logged or surfaced in last_error
Silent data loss on SIEM partial failure	✓ Yes	Strict per-record error parsing (Confluent); idempotent batch delivery via UNIQUE(destination_id, r2_key)
Motivated adversary with shell access	✗ No	OS sandboxing
LLM hallucination / jailbreak	✗ No	LLM output filters
Kernel exploit	✗ No	VM isolation