Catching Hardcoded Secrets Before They Hit Disk: Aider

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 ask Aider to scaffold a new API integration. The agent writes a client.ts file and — to make the code "just work immediately" — embeds the API key directly:

const client = new APIClient("sk_live_abc123SECRETKEY...", { version: "v2" });

Without a guardrail, this file is saved, staged in the next commit, and lands in repository history. SSG's no-secrets write rule intercepts before the file is created.

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

Give SSG context

SSG intercepts write_file and edit_file calls via the SSG MCP Server integration for Aider sessions and evaluates file content before saving.

Required context

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])[A-Za-z0-9_\-]{10,}"
  MESSAGE "Hardcoded credentials detected. Use environment variables instead."
}

Optional context

Scope to non-test files to avoid blocking test fixtures:

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

What SSG does

SSG reads the full content payload of the write call and runs your regex before any bytes touch the filesystem. Aider receives the block and can reformulate — writing the env var reference instead.

Ask the agent to use an environment variable

The file was blocked: it contained a hardcoded API key.
Rewrite using process.env.API_SECRET_KEY and add the key to .env.example (not .env).

The agent rewrites the file. process.env.API_SECRET_KEY doesn't match the regex, so the write proceeds.

Apply the same rule across your entire codebase

The .sigmashake/rules/ directory applies to all write calls across every subdirectory. One secrets.rules file protects your entire monorepo — no per-package configuration needed.

See every secret attempt in your audit trail

Run ssg dashboard to see a searchable log of all blocked write attempts. The content snippet (truncated for safety) is shown alongside the matching rule and timestamp. List no-secrets hits with ssg audit search --rule-id no-secrets.

How your regex shapes what gets caught

The example pattern catches common key prefixes. Expand it with your specific key formats (e.g., AKIA for AWS, xoxb- for Slack). Start in ASK mode to review matches before promoting to DENY. Test with echo '{"tool":"Write","input":{"file_path":"src/client.ts","content":"sk_live_abc123"}}' | ssg eval.

Check the rule against test fixtures

Most projects have test files with example-looking keys. Use a NOT ENDS_WITH ".test.ts" path condition to avoid blocking legitimate test fixtures. Run ssg lint after any regex change to catch syntax errors.