Secret scanning often starts at Git. AI coding agents can make that too late.

They can read local files, summarize logs, run commands, and transform sensitive context before anything is committed. shk is a local-first CLI for that messy pre-commit space: scan secrets and PII, mask prompts, and install managed hooks for Claude Code, Cursor, and Codex.

The problem is no longer just "secret reaches Git"

Most secret-scanning workflows are built around a familiar boundary: stop credentials before they land in Git, CI logs, or a release artifact.

AI coding agents move that boundary earlier.

An agent might read a file while following an import chain. It might summarize a pasted error log. It might run a shell command that prints .env contents. It might create a new file that quietly contains a token from earlier context. None of that requires a commit.

That is the gap shk is trying to cover: the local, messy, pre-commit space where AI tools actually operate.

What shk does in practice

shk is not one more dashboard you have to check. It is a single Rust binary that you put around the workflows where sensitive context tends to leak:

• Before sharing context with an AI tool, use shk mask to redact secrets and PII from a prompt, log, or snippet.
• Before an AI tool reads, writes, fetches, or runs something, use managed hooks to audit or block risky operations.
• Before a commit or pull request, use the same scanner through Git pre-commit hooks and GitHub Actions.

That gives you one policy file, one set of rules, and one exit-code contract across local use, AI hooks, Git, and CI.

A quick tour

Install the latest release:

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/Kazuki-tam/security-harness-kit/releases/latest/download/shk-cli-installer.sh | sh

Windows users can install from PowerShell:

powershell -c "irm https://github.com/Kazuki-tam/security-harness-kit/releases/latest/download/shk-cli-installer.ps1 | iex"

Both shk and security-harness-kit resolve to the same CLI.

Start with a policy file:

shk init

Scan the current project:

shk scan .

Example output:

3 findings

HIGH  secret.openai_api_key  src/app.ts:12    Possible OpenAI API key detected
MED   pii.ja.phone           config/dev.ts:5  Japanese phone number detected
MED   pii.en.ssn             docs/test.md:8   US Social Security Number detected

Need a machine-readable report for automation? Use JSON. Raw matched values are not emitted; findings use redacted_value: "[REDACTED]".

shk scan . --json

Need to paste a production log into an AI chat? Mask it first:

shk mask < prompt.txt

Need to protect the commit path?

shk scan --staged
shk hooks install

The basic loop is intentionally boring: scan, review, mask, and block only when a configured threshold is met.

The AI-specific part: managed hooks

The more interesting piece is shk hooks install-ai.

Instead of relying on you to remember to scan every prompt, shk can write managed hook entries into supported AI tool configs:

# Preview the changes first.
shk hooks install-ai --dry-run

# Start in audit mode: log findings, never block.
shk hooks install-ai --audit

# Or target one tool.
shk hooks install-ai --tool cursor
shk hooks install-ai --tool claude-code --global

Project-level installs are the default. Global installs write to the user-level config for the selected tool.

Supported integrations:

The managed entries are tagged so they are easy to identify later ("_shk_managed": true in JSON configs, or # shk-managed-start / # shk-managed-end in shell and TOML blocks).

It checks intent, not only text

Secret scanners usually inspect content. AI hooks also need to inspect actions.

In hook mode, shk reads the AI tool's JSON hook payload and runs an action guard before scanning extracted text. The guard looks for operation shapes such as:

• Reads or writes involving sensitive paths.
• Commands that dump .env-style files.
• Destructive recursive removal.
• Direct database mutation commands.
• Privilege or system configuration changes.
• External transfer commands.
• Package-manager operations.

The default recommended profile is conservative. A strict profile can also block opaque execution forms such as bash -c, python -c, and node -e, because pretending to safely interpret every nested command string is usually worse than being explicit about the risk.

You can tune this in shk.toml with [action_guard] allow and deny patterns.

Audit first, then block

Hooks make decisions through exit codes, so the contract is small:

--audit always exits 0. Post-tool hooks also always exit 0, because the operation already happened and the useful behavior is reporting, not pretending to undo it.

That makes rollout straightforward:

shk hooks install-ai --audit

Let it run for a few days. Review .shk/audit.log. The log is metadata-only: counts, tool name, hook phase, display path, suppressed count, and maximum severity. It does not store raw matched values.

Once the noise level is acceptable, reinstall without --audit and let high-severity pre-hook findings block.

Same binary for Git and CI

AI hooks are the new boundary, but Git still matters.

Install a managed pre-commit hook:

shk hooks install

Generate a GitHub Actions workflow:

shk ci init github

The generated workflow installs the prebuilt release binary and runs:

shk scan . --json --fail-on high

It also uses a few defaults I wanted out of the box:

• permissions: contents: read for minimal GITHUB_TOKEN scope.
• concurrency: cancel-in-progress: true so newer PR pushes cancel stale runs.
• actions/checkout@v6.
• Release installer instead of cargo install, so CI does not rebuild a Rust toolchain.

You can also generate rollout variants when you need them:

• shk ci init github --mode audit for non-blocking CI adoption.
• shk ci init github --shk-version v0.2.3 for reproducible pinned installs.

A few workflows beyond scanning

These are the commands that make shk feel less like a one-off scanner and more like a local security harness:

• shk doctor checks project hygiene, including ignore coverage and plaintext .env files.
• shk doctor ignore --fix appends missing required patterns to .gitignore.
• shk env dotenvx import-keys .env.keys moves dotenvx private keys into the OS credential store.
• shk env dotenvx run -- npm test injects stored dotenvx keys only into the child process.
• shk secrets push pushes dotenv payloads into AWS Secrets Manager or GCP Secret Manager through the official aws / gcloud CLIs, with dry-run, audit logging, and PII pre-scan.
• shk skills install deploys an embedded agent skill for Claude Code, Codex, and Cursor so agents know how to call shk in the project.

All of these are optional. The tool is still useful if you only use scan, mask, and hooks.

Suppression without pasting secrets into config

False positives happen. Test fixtures happen. Public demo values happen.

shk supports a few suppression shapes:

• Inline comments such as # shk-ignore <rule_id> and # shk-ignore-next-line <rule_id>.
• Path-based [[allowlist]] entries in shk.toml.
• Value-specific suppression using value_hash = "sha256-hmac:...".

The value hash is not encryption. It is a deterministic HMAC-SHA256 fingerprint over the raw value and rule id, so someone with the candidate value can recompute it. Its purpose is narrower and practical: your policy file should not become the place where people paste the secret they are trying to suppress.

Expired allowlist entries turn into low-severity warning findings instead of silently disappearing.

What it intentionally does not promise

Security tooling gets dangerous when it overstates its guarantees, so here is the honest scope.

shk is pattern-based. Built-in rules combine hand-tuned shk detections with generated secret.gitleaks.* rules adapted from the gitleaks default configuration. That covers many common providers and formats, but false positives and false negatives are both possible.

The PII rules are designed for "do not paste this into an AI prompt" hygiene. They are not compliance evidence.

The action guard is heuristic. It can flag risky operation shapes in hook payloads, but it is not a shell interpreter and should not pretend to be one.

shk is also not a replacement for a secret manager, a cloud provider's scanning features, or a dedicated enterprise secret-scanning platform. It is a local guardrail layer for the part of development where AI tools read, transform, and generate context.

Try it on an existing repo

The smallest useful sequence is:

shk init
shk scan .
shk hooks install-ai --audit

If the audit log looks reasonable after a short soak period, reinstall without --audit and block on high-severity pre-hook findings. If it is noisy, tune [thresholds], [[allowlist]], and [action_guard] first.

The goal is not to make the tool dramatic. The goal is to make secrets, PII, and risky AI operations visible before they leave the local development boundary.

• Repo: github.com/Kazuki-tam/security-harness-kit
• Docs: Installation, Commands, Configuration, Detection Model, and GitHub Actions integration are linked from the README.
• License: MIT.

Issues, rule contributions, and false-positive reports are welcome. The rule set gets better as more real codebases run through it.