Policy Recipes

Most guardrail tools give you allow or deny. SSG adds a third option: FORCE, which rejects the original call and returns a substitute instruction the agent reads and acts on immediately, redirecting itself to the right tool without any human in the loop. The decision table in ./why-sigmashake.md covers all six decisions; Rule Syntax has the full DSL reference. This page is the practical complement: four complete, copy-paste policies that cover the scenarios teams reach for first.

How to use these recipes

Copy a block into .sigmashake/rules/<name>.rules, then validate and test:

ssg lint .sigmashake/rules/            # syntax-check every file in the dir
echo '{"tool":"Bash","input":{"command":"grep -r foo ."}}' | ssg eval --verbose   # prints the decision + matched rule (rule=...) to stderr

ssg lint exits 1 on any parse error and reports native-compatibility warnings. ssg eval evaluates a tool call against your loaded rules and prints the decision as JSON; add --verbose to also log the matched rule (rule=<id>, or rule=none) and the decision to stderr.

Recipe 1 — Block secrets

What it does. Three rules cover the three attack surfaces for secrets: reading secret-bearing files, writing to them, and piping them to the network.

Why this shape. The machine-wide strict-secrets profile (see Policy Profiles) blocks writes to .env, .pem, and .key paths and is the right machine-wide backstop. This project-rule form goes further: it also blocks reads and egress, and adds .aws credential directories, so a project with stricter requirements can layer it on top without disabling the profile.

rule block-secret-file-reads {
  enabled true
  priority 90
  severity error
  CATEGORY credential-access
  TAGS secrets, attack.t1552
  DENY read
  IF path GLOB "**/.env"
  OR path GLOB "**/.env.*"
  OR path ENDS_WITH ".pem"
  OR path ENDS_WITH ".key"
  OR path GLOB "**/credentials"
  OR path GLOB "**/.aws/**"
  MESSAGE "Reading secret-bearing files is blocked. Inject secrets at runtime instead."
}

rule block-secret-file-writes {
  enabled true
  priority 90
  severity error
  CATEGORY credential-access
  TAGS secrets, attack.t1552
  DENY write
  IF path GLOB "**/.env"
  OR path GLOB "**/.env.*"
  OR path ENDS_WITH ".pem"
  OR path ENDS_WITH ".key"
  MESSAGE "Writing to secret-bearing files is blocked. Commit a .example template instead."
}

rule block-secret-egress {
  enabled true
  priority 95
  severity error
  CATEGORY credential-access
  TAGS secrets, exfil, attack.t1041
  DENY execution
  IF command CONTAINS ".env"
  AND command CONTAINS "curl"
  OR command CONTAINS ".env"
  AND command CONTAINS "wget"
  MESSAGE "Piping a secret file to the network is blocked."
}

AND/OR grouping note. The block-secret-egress conditions read as two groups joined by OR: (command CONTAINS ".env" AND command CONTAINS "curl") OR (command CONTAINS ".env" AND command CONTAINS "wget"). Within each group, AND lines narrow the match; OR starts a fresh group. See Rule Syntax — AND/OR logic for the full semantics.

Recipe 2 — Require approval for infra

What it does. An ASK gate pauses execution before any infrastructure-mutating command and routes the request to the SSG dashboard for human approval.

Why this shape. The built-in deploy-guard profile (see Policy Profiles) covers the same commands machine-wide. Use this project-rule form when you want the gate scoped to one repository, or when you need to extend the command list beyond what the profile matches.

ASK requires a PROMPT field — the text shown to the approver in the dashboard and returned to the agent alongside the decision.

rule approve-infra-changes {
  enabled true
  priority 80
  severity warning
  CATEGORY process-control
  TAGS infra, deploy
  ASK execution
  IF command CONTAINS "terraform apply"
  OR command CONTAINS "terraform destroy"
  OR command CONTAINS "kubectl apply"
  OR command CONTAINS "kubectl delete"
  OR command CONTAINS "helm upgrade"
  OR command CONTAINS "helm install"
  MESSAGE "Infrastructure change requires human approval."
  PROMPT "Allow this infrastructure-mutating command to run?"
}

Tuning. Add OR command CONTAINS "cdk deploy" or OR command CONTAINS "pulumi up" to extend coverage to other IaC tools. To escalate to a hard block with no approval path, change ASK to DENY.

Recipe 3 — Force code search through the graph or index

What it does. When the agent issues a recursive shell search (grep -r, find), this rule rejects the call and returns a substitute instruction. The agent reads the instruction and issues a compliant call — no human in the loop, no interruption.

Why this shape. This is the FORCE mechanic in practice. Per Rule Syntax — FORCE decisions, FORCE blocks the original call and appends the SUBSTITUTE text to the stderr block message surfaced on exit code 2. The agent receives that output, pivots to the suggested tool, and emits a new call. The result is a productivity redirect, not a security block: the agent keeps moving, it just uses a faster, scoped tool instead of a full-tree shell scan.

The SUBSTITUTE text includes a ripgrep escape hatch (rg <pattern>) for the literal/log/config searches that an index cannot answer — so the agent is never left without an option.

rule force-search-through-index {
  enabled true
  priority 70
  severity warning
  CATEGORY code-execution
  TAGS search, productivity
  FORCE execution
  IF command CONTAINS "grep -r"
  OR command CONTAINS "grep -R"
  OR command CONTAINS "grep --recursive"
  OR command STARTS_WITH "find "
  MESSAGE "Recursive shell search is redirected to the code index for code/architecture/relationship queries (faster, scoped)."
  SUBSTITUTE "graphify query \"<your question>\"   (escape hatch for literal/log/config: rg <pattern>)"
}

Tuning. If you do not use graphify, replace the SUBSTITUTE value with your project's index tool (e.g., rg, ast-grep, a custom CLI). The FORCE mechanic works with any substitute text — the agent treats it as an instruction. Compare with Recipe 4 below, which uses DENY instead; see the cheat-sheet at the bottom of this page for guidance on when to use each.

Recipe 4 — Deny recursive shell scans

What it does. Hard-blocks recursive shell searches with no automatic alternative.

Why this shape. This is the DENY counterpart to Recipe 3, and the contrast is the point: DENY stops the agent cold; FORCE redirects it. Use DENY when you want a hard wall — for example, on a production-access machine where you do not want any recursive scan attempted regardless of what the agent intends to do next. For day-to-day development work, Recipe 3 (FORCE) is more useful because it keeps the agent productive; this recipe is the opt-in for when productivity is not the constraint.

rule deny-recursive-shell-scans {
  enabled true
  priority 60
  severity warning
  CATEGORY code-execution
  TAGS search
  DENY execution
  IF command CONTAINS "grep -r"
  OR command CONTAINS "grep -R"
  OR command CONTAINS "grep --include"
  OR command STARTS_WITH "find "
  MESSAGE "Recursive shell scans are disabled on this project. Use the code index or ripgrep (rg) for a bounded search."
}

Note. Do not deploy both Recipe 3 and Recipe 4 in the same rule set — they match overlapping commands. Pick one based on whether you want the agent redirected (FORCE) or stopped (DENY).

Choosing a decision

Decision	When to reach for it
`ALLOW`	Explicitly permit a call that a lower-priority rule would block. Use to carve safe exceptions above a broad DENY.
`LOG`	Allow the call but record it. Use during rollout to observe what matches before committing to DENY.
`SHADOW`	Allow silently and log for monitoring. Use when you want telemetry without any visible signal to the agent.
`ASK`	Pause and route to a human for approval. Use for irreversible or high-stakes operations where a human must be in the loop. Requires `PROMPT`.
`FORCE`	Reject the call and return a substitute instruction the agent reads and follows. Use to redirect the agent to a better tool. Agent self-corrects; no human needed. Requires `SUBSTITUTE`.
`DENY`	Hard stop. No automatic alternative. Use when you want the call to fail with no recovery path — for security walls, not productivity redirects.

The key distinction: FORCE keeps the agent working by steering it; DENY stops it. For most development policies, FORCE is the more useful choice.

How to use these recipes​

Recipe 1 — Block secrets​

Recipe 2 — Require approval for infra​

Recipe 3 — Force code search through the graph or index​

Recipe 4 — Deny recursive shell scans​

Choosing a decision​

See also​