Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.sigilix.ai/llms.txt

Use this file to discover all available pages before exploring further.

Secrets leak into commits all the time. A test config copy-pasted from staging. A debug console.log of an auth header. A .env.local file accidentally committed. The LLM specialists might catch these — but might isn’t good enough for a credential that’s now in your git history. Sigilix runs a dedicated regex sweep before the LLM specialists. It looks for the canonical patterns of major providers and surfaces matches as critical-severity findings.

​
What it catches

ProviderPattern surface
AWSAKIA[0-9A-Z]{16} (access keys), ASIA[0-9A-Z]{16} (temporary credentials)
Stripesk_live_[0-9a-zA-Z]{24,} (live secret), sk_test_[0-9a-zA-Z]{24,} (test secret), rk_live_[0-9a-zA-Z]{24,} (restricted key)
GitHubghp_[0-9a-zA-Z]{36} (personal access token), gho_…, ghu_…, ghs_…, ghr_…
GCPPrivate-key blocks in service-account JSON (-----BEGIN PRIVATE KEY-----)
Slackxoxb-…, xoxp-…, xoxa-…, xoxr-…
OpenAI / Anthropicsk-[a-zA-Z0-9]{32,}, sk-ant-[a-zA-Z0-9-]{40,}
Generic JWTeyJ[a-zA-Z0-9_-]+\.eyJ[a-zA-Z0-9_-]+\.[a-zA-Z0-9_-]+
The scanner runs against the added diff lines, so it doesn’t flag secrets that have been in the file all along — only newly introduced ones. (Pre-existing secrets in the repo are a different problem; Sigilix isn’t a git-history scanner.)

​
How findings appear

A secret-scanning hit posts as an inline finding at the matched line: 
[Warden] Critical: AWS access key detected
config/staging.ts:42 — line matches AKIA[0-9A-Z]{16}.

If this is a real credential, rotate it immediately (the key is now in git history).
If this is a placeholder, replace with a recognized fake (e.g., AKIAIOSFODNN7EXAMPLE).
The verdict is set to Request changes, regardless of any other findings on the PR.

​
Why it’s run before the LLM

Two reasons:
  1. Determinism. A regex match on AKIA[0-9A-Z]{16} is a fact, not a judgment call. The LLM doesn’t need to weigh whether it’s a “real” secret — the pattern is the pattern.
  2. Token efficiency. The scanner runs in microseconds and finds the high-value catches. The LLM specialists are freed to reason about what to do (does this key get used? is it logged?) instead of scanning for syntactic patterns.
When the LLM specialists run, the secret-scanner findings are already in their context as authoritative facts. Warden, for instance, gets prompted: “The secret scanner flagged an AWS access key on line 42. Consider its blast radius — what code paths consume this value?”

​
False positives

The scanner is tuned for precision over recall. The published patterns are narrow enough that pattern-only matches are real ~98% of the time on real codebases. Common false-positive sources and their handling:
SourceHandled by
AKIAIOSFODNN7EXAMPLE (AWS docs placeholder)Allowed — exact match suppressed
sk_test_… keys committed to public sample appsStill flagged — test keys are still credentials that should be in .env
Hex-string lookalikes that match ghp_[0-9a-zA-Z]{36}Practically nonexistent at 36-char length
If the scanner produces a false positive on your repo, the right response is:
  1. Reply to the finding’s thread with “false positive: $reason” — that’s a feedback signal the review memory consumes.
  2. If it’s a stable pattern, file a Linear issue with the lookalike and the pattern that conflicts.

​
Repo-specific patterns

The built-in scanner covers major providers. For your own internal credentials (partner API keys, internal bearer tokens, etc.), use deterministicChecks: 
{
  "deterministicChecks": [
    {
      "id": "no-acme-internal-key",
      "pattern": "ACME_KEY_[A-Z0-9]{32}",
      "severity": "critical",
      "message": "Internal Acme key detected — rotate via the internal-creds system."
    }
  ]
}
deterministicChecks runs in the same pre-LLM phase as the built-in scanner and produces findings of the same shape.

​
What it doesn’t do

ConcernReality
Catch secrets renamed to fake-looking variables (const x = "AKIA...")The pattern matches the secret regardless of the variable name — the value is what we scan.
Block the merge automaticallySigilix can’t block a merge; GitHub branch protection does. But the verdict is Request changes, so a required-reviewers: sigilix rule will hold the PR.
Scan unchanged files / git historyOut of scope — Sigilix reviews PRs, not the repo. For history-wide scanning, use a dedicated tool like trufflehog.
Rotate the secret for youOut of scope — you have to rotate it in the issuing provider’s console. The finding text reminds you.

​
Disabling

Secret scanning cannot be disabled per-repo — it’s part of the core pipeline. If a specific pattern produces persistent false positives on your codebase, file a ticket; the built-in patterns are tuned upstream. (In the unlikely case you need to run Sigilix with secret scanning fully off — for example, on a repo whose entire purpose is to test secret-detection tools — contact support.)

Deterministic Checks

The pre-LLM signal layer end-to-end.

Dependency Vulnerabilities

The other authoritative pre-LLM channel.