What would you like to be added?

A pre-flight secret scanner that detects and redacts credentials, API keys, connection strings, and PII from the context window before it is transmitted to the Gemini API. This would prevent accidental credential leakage during normal agent operations.

The Gap

Gemini CLI has no secret detection mechanism. When the agent reads a file, its full contents — including any embedded credentials — are sent to the Gemini API in the context window:

User: "Fix the database connection"
Agent reads .env:
  DATABASE_URL=postgres://admin:s3cretP@[email protected]:5432/app
  STRIPE_SECRET_KEY=sk_live_51HG7...
  AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCY...

→ All three credentials are sent to the API, unfiltered.

.gitignore patterns only prevent file discovery (glob, search). If the agent explicitly reads a file path — which it routinely does when asked to debug database connections, fix API integrations, or troubleshoot deployments — ignore patterns don't block it.

The strict sandbox profile allows reads from ~/.gemini, ~/.config, ~/.npm, ~/.cache, all of which may contain tokens or credentials.

Proposed Solution: Pre-Flight Redaction Pipeline

A multi-stage scanner that intercepts context before API transmission:

Stage 1 — Regex Pattern Scanner (deterministic, fast):

Stage 2 — Entropy-Based Detection (optional, catches novel formats):

High-entropy strings (Shannon entropy > threshold) in value positions are flagged as potential secrets even if they don't match known patterns. Similar to trufflehog / detect-secrets.

Stage 3 — Redaction:

Detected secrets are replaced with type-tagged placeholders:

DATABASE_URL=[REDACTED:connection_string]
STRIPE_SECRET_KEY=[REDACTED:api_key]
AWS_SECRET_ACCESS_KEY=[REDACTED:aws_credential]

The agent can still see the structure (there's a DATABASE_URL, it's a postgres connection) without seeing the actual credentials. This preserves the agent's ability to reason about the code while protecting the secrets.

Integration Options

Option A — External safety checker (recommended):

Register as an external checker targeting read_file and tool results. The checker scans file content before it reaches the model:

[[safety_checker]]
toolName = ["read_file"]
priority = 70

[safety_checker.checker]
type = "external"
name = "secret-scanner"
required_context = ["environment"]

[safety_checker.checker.config]
action = "redact"           # "redact" | "warn" | "block"
entropy_threshold = 4.5     # Shannon entropy threshold
custom_patterns = []        # Additional regex patterns

The checker would return ask_user with the detected secrets listed, letting the user decide whether to proceed with redacted content.

Option B — Context pre-processing hook:

Use the BeforeTool hooks system to scan tool results (AfterTool) and redact secrets before they enter the conversation history.

Option C — Built-in redaction in the content pipeline:

Add a redaction pass to the content generator pipeline that scans outbound context before API calls. This is the most thorough but requires deeper integration.

Configuration

// ~/.gemini/settings.json
{
  "security": {
    "secretScanning": {
      "enabled": true,
      "action": "redact",        // "redact" | "warn" | "block"
      "patterns": "default",     // "default" | "strict" | "custom"
      "entropyScanning": false,  // Enable entropy-based detection
      "allowedPaths": [],        // Paths exempt from scanning (e.g., test fixtures)
      "customPatterns": []       // Additional regex patterns
    }
  }
}

Why is this needed?

1. This is the most common real-world data leakage scenario. Developers routinely ask agents to "fix the database connection" or "debug the API integration" — tasks that naturally lead the agent to read credential files. Every such interaction sends unfiltered credentials to the API.

2. .gitignore is not a security boundary. It prevents file discovery but not explicit reads. The agent can and does read_file .env when directed to by the task context.

3. The sandbox doesn't help. Even the strict sandbox profile allows reads from ~/.config, ~/.cache, and other paths where tokens may reside. And sandbox is opt-in.

4. Every other major CLI tool has this. GitHub CLI redacts tokens from debug output. AWS CLI masks credentials in logs. Docker CLI warns about secrets in build context. Gemini CLI is an outlier in sending credentials to a remote API with zero scanning.

5. The fix is deterministic and fast. Regex-based scanning adds negligible latency. No LLM calls needed. False positive rate for well-known patterns (AWS keys, GitHub tokens, PEM headers) is near zero.

6. Users cannot reasonably audit every file read. In a typical session, the agent may read dozens of files. The user cannot check each one for embedded credentials. Automated scanning is the only scalable solution.

Additional context

• Related: Issue #25829 (Causal Armor), Issue #25836 (shell deobfuscation)
• The safety checker framework (PR #12504) supports external checkers that could implement this
• Reference implementations exist in detect-secrets (Yelp), trufflehog (TruffleHog), and gitleaks
• OWASP Top 10 for LLM Applications (2025) lists "Sensitive Information Disclosure" as a top risk
• A reference implementation with regex scanner, env masker, and redaction engine exists at gemini-cli-provenance-armor