Secret scanning in artifacts

Hardcoded keys get redacted before saving to disk.

The problem

When an agent analyzes your code, it reads files that may contain API keys, tokens, and credentials. The analysis results get saved as JSON artifacts in .nanostack/. Without scanning, those artifacts could contain your Stripe key in a code snippet or your AWS secret in an error message. Anyone with access to the artifacts (teammates, CI logs, the git history) would see those secrets in plaintext.

What gets scanned

Every artifact is scanned before being written to disk. The scanner checks for known key formats from these providers:

  • Stripe — sk_live_, sk_test_, pk_live_, pk_test_, rk_live_, rk_test_
  • AWS — AKIA access keys, secret access keys matching the 40-char base64 pattern
  • GitHub — ghp_, gho_, ghu_, ghs_, ghr_ tokens
  • Slack — xoxb-, xoxp-, xoxs-, xapp- tokens
  • OpenAI — sk- keys with the OpenAI length and character pattern
  • Anthropic — sk-ant- keys
  • Generic — base64 strings longer than 40 characters following common secret patterns, RSA/ECDSA private key headers

Redaction format

When a secret is detected, the first 8 characters are preserved and the rest is replaced with [REDACTED]. Preserving the prefix lets you identify which key was exposed without revealing the full value.

Before: "api_key": "sk_live_4eC39HqLyjWDarjtT1zdp7dc"
After:  "api_key": "sk_live_[REDACTED]"

Before: "token": "ghp_ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefgh"
After:  "token": "ghp_ABCD[REDACTED]"

The 8-character prefix is configurable. Set it to 0 if you want full redaction with no prefix:

// .nanostack/config.json
{
  "secrets": {
    "prefix_length": 0
  }
}

Integrity checksums

Every artifact includes a SHA-256 checksum of the content before and after redaction. This serves two purposes:

  • Tamper detection— if the artifact is modified after creation, the checksum will not match. Skills that read artifacts can verify integrity.
  • Redaction proof— the pre-redaction checksum is stored but the pre-redaction content is not. You can prove that redaction happened and that the original content hashed to a specific value, without being able to recover the original.
{
  "integrity": {
    "sha256_pre_redaction": "a1b2c3d4...",
    "sha256_post_redaction": "e5f6g7h8...",
    "secrets_redacted": 2,
    "scan_timestamp": "2026-03-28T14:32:00Z"
  }
}

What about .env files?

The scanner only processes nanostack artifacts. It does not modify your .env files or source code. For protection against committing secrets to git, use a dedicated tool like git-secretsor your CI provider's secret scanning. Nanostack's scanner specifically addresses the risk of secrets leaking through the sprint's own output files.

Custom patterns

Add custom patterns for internal key formats:

// .nanostack/config.json
{
  "secrets": {
    "custom_patterns": [
      {
        "name": "internal-api-key",
        "pattern": "myco_[a-zA-Z0-9]{32}",
        "prefix_length": 5
      }
    ]
  }
}
Previous← /freezeNext/conductor →