keygate: A Fast Pre-Commit Guardrail Against Secret Leaks

YUICHI KANEKO — Fri, 24 Apr 2026 05:06:55 +0000

Accidentally committing an API key, password, or private key is still one of the easiest ways to create a serious security incident. The problem gets worse as development speeds up: larger diffs, faster iterations, and more code being drafted by AI coding agents before a human reviews every line.

That is why I built keygate: a lightweight Git pre-commit hook that scans only staged added lines and blocks likely secrets before they enter repository history.

keygate is intentionally narrow in scope. It is not trying to replace full-repository scanners or cloud security platforms. Instead, it focuses on the moment that matters most in local development: right before git commit succeeds.

GitHub: https://github.com/kanekyuichi/keygate
PyPI: https://pypi.org/project/keygate/

Why I built it

Most secret leaks are not dramatic breaches. They start as small mistakes:

a real API key copied into a config file during debugging
a password left in a test fixture
a .env value pasted into code "just for now"
a generated diff that includes credentials no one noticed in review

Once committed, the value is part of Git history. Even if you delete it later, the exposure may already have happened.

Existing tools are useful, but I wanted something optimized for the local developer workflow:

fast enough for a Git hook
offline by default
focused on staged changes, not a full repo sweep
practical about false positives
usable both by humans and by AI agents

What keygate does

keygate combines multiple signals instead of relying on a single regex:

rule-based detection for known formats such as AWS keys, OpenAI keys, GitHub tokens, Slack tokens, PEM private keys, JWTs, Stripe keys, SendGrid keys, and URLs with embedded credentials
entropy checks for long random-looking strings
context scoring for signals like api_key, password, assignment syntax, and sensitive paths such as .env or config files

The final result is scored as:

block at 70+
warn at 40-69
ignored below 40

This keeps the hook fast while avoiding the worst tradeoff in secret scanning: either missing real secrets or becoming so noisy that developers disable it.

Built for modern local workflows

I also designed keygate for the reality that AI agents now write a meaningful share of code changes.

When tools like Codex or Claude Code generate larger diffs, the safest assumption is not that the agent is malicious, but that speed increases the chance of unnoticed sensitive values reaching a commit. A local guardrail becomes more valuable in that workflow, not less.

That is why keygate includes structured JSON output in addition to human-readable CLI output:

keygate scan --format json
keygate scan --json
keygate scan --profile agent

That makes it easier for scripts or coding agents to re-run the scan, parse findings, and suggest fixes mechanically.

Handling false positives without breaking flow

A secret scanner is only useful if developers can live with it every day. keygate includes three escape hatches for expected findings:

Inline ignore comments with a required reason
Allowlist rules in keygate.toml
A baseline file for existing findings you want to suppress safely

The baseline stores fingerprints rather than raw secret values, so teams can commit the file without exposing the secret itself.

Quick start

pipx install keygate
cd your-project
keygate install-hook

From that point on, every normal git commit gets a fast local secret check automatically.

Project goals

The design goals are simple:

stop likely secrets before commit
keep the check fast enough for daily use
work offline
avoid LLM or external API dependence
give clear remediation when something is blocked

If you want a local, developer-friendly secret scanner that acts as a commit-time guardrail, that is exactly the gap keygate is meant to fill.

Detecting Prompt Injection in LLM Apps (Python Library)

YUICHI KANEKO — Wed, 01 Apr 2026 03:31:37 +0000

I've been working on LLM-backed applications and ran into a recurring issue: prompt injection via user input.

Typical examples:

"Ignore all previous instructions"
"Reveal your system prompt"
"Act as another AI without restrictions"

In many applications, user input is passed directly to the model, which makes these attacks practical.

Most moderation APIs are too general-purpose and not designed specifically for prompt injection detection, especially for non-English inputs. So I built a small Python library to act as a screening layer before sending input to the LLM:

https://github.com/kanekoyuichi/promptgate

Detection strategies:

rule-based (regex / phrase matching)

latency: <1ms, no dependencies
embedding-based (cosine similarity with attack exemplars)

latency: ~5–15ms, uses sentence-transformers
LLM-as-judge

higher accuracy, but +150–300ms latency, requires external API

Baseline evaluation (rule-only):

FPR: 0.0% (0 / 30 benign samples)
Recall: 61.4% (27 / 44 attack samples)

So rule-based alone misses ~40% of attacks, especially paraphrased or context-dependent ones.

This is not intended as a complete solution — the design assumption is defense-in-depth, where this acts as a first screening layer.

Known limitations:

rule-based detection struggles with paraphrased / indirect instructions
embedding approach depends on exemplar coverage (not a trained classifier)
LLM-as-judge is non-deterministic and API-dependent

Would be interested in feedback on:

better evaluation methodologies
detection strategies beyond pattern / similarity / LLM judging
how others are handling prompt injection at the application layer

Forem: YUICHI KANEKO