Blocking Hardcoded API Keys Before They Hit Git

Correction note (2026-10-13). The per-call timings and latency figures that appeared in this article had no benchmark behind them and were removed. Sample output in this article is illustrative, not a recorded run. The only published measurement is p50 0.39 ms and p99 1.91 ms (sigmashake-bench daemon-socket run, 2026-06-10, ssg 0.29.156, n=500). Sub-2 ms evaluation is a design target. ssg eval reads the tool call as JSON on stdin and has no --content, --content-file, --file or positional form. ssg dashboard has no --port or --notify-slack flag; use ssg serve, ssg dashboard open and ssg audit search --rule-id.

Describe the task

You've asked Claude Code to scaffold a new payment service. It writes src/payments/client.ts and — trying to be helpful — hardcodes your Stripe secret key directly into the file so the code "just works" when you run it:

const stripe = new Stripe("sk_live_abc123...", { apiVersion: "2024-06-20" });

Without a guardrail, this file saves, gets committed in the next git add -A, and lands in your repo history forever. SSG's no-secrets write rule intercepts the write_file tool call before the file is created.

# illustrative sample output
[BLOCK] write_file › src/payments/client.ts — rule: no-secrets
Reason: Content matches API key pattern. Use environment variables.

Give SSG context

SSG intercepts write_file and edit_file tool calls and evaluates the file content against your rules — not just the command.

Required context

A .sigmashake/rules/secrets.rules file with a regex pattern rule:

rule no-secrets {
  enabled true
  priority 100
  severity error
  DENY write
  IF content REGEX "([sS][kK]_[lL][iI][vV][eE]_|[aA][pP][iI][-_]?[kK][eE][yY]|[sS][eE][cC][rR][eE][tT][-_]?[kK][eE][yY]|[pP][rR][iI][vV][aA][tT][eE]_[kK][eE][yY])[A-Za-z0-9_\-]{10,}"
  MESSAGE "Hardcoded credentials detected. Use environment variables instead."
}

Optional context

Scope the rule to specific file patterns to reduce false positives in test fixtures:

rule no-secrets {
  enabled true
  priority 100
  severity error
  DENY write
  IF path NOT ENDS_WITH ".test.ts"
  AND content REGEX "[sS][kK]_[lL][iI][vV][eE]_[A-Za-z0-9]{20,}"
  MESSAGE "Stripe live key detected in non-test file. Move to .env."
}

What SSG does

SSG reads the full content payload of the write_file call and runs your regex against it before any bytes touch the filesystem. The block appears as a tool error to Claude Code, which can then reformulate — writing the correct env var reference instead.

Ask the agent to use an environment variable

After the block, guide Claude Code with the error context:

The file was blocked because it contained a hardcoded API key.
Rewrite using process.env.STRIPE_SECRET_KEY instead of the literal value.

The agent rewrites the file, SSG re-evaluates — process.env.STRIPE_SECRET_KEY doesn't match the regex, so the write proceeds normally.

See every secret attempt in your audit trail

Run ssg dashboard to see a searchable log of all blocked write attempts, including the matching content snippet (truncated for safety). Your security team can list no-secrets hits with ssg audit search --rule-id no-secrets.

Apply the same rule across your entire monorepo

The .sigmashake/rules/ directory applies to all agent tool calls in the repo. If you have multiple services, a single secrets.rules file covers write calls in every subdirectory — you don't need per-package configuration.

How your regex shapes what gets caught

The example pattern catches common formats but may miss obfuscated keys. Start with broad patterns in ASK mode (so the agent surfaces potential matches for human review) before promoting to DENY. Run echo '{"tool":"Write","input":{"file_path":"src/client.ts","content":"sk_live_abc123"}}' | ssg eval to test your regex before deploying.

Check the rule against test fixtures

Most projects have test files with example API keys that look real but are fake. Use a NOT ENDS_WITH ".test.ts" condition (or a .test. path exclusion) to avoid blocking legitimate test fixtures. Run ssg lint after any regex change to catch syntax errors before the agent encounters them.