Use case

Security: avoiding secret leaks with AI

Generative AI in the development workflow creates new vectors for secret leaks: API keys, tokens, credentials sent in prompts. Here is how to secure your practices without slowing down productivity.

8 min read
SecuritySecretsAIDevSecOpsRisks
⚡ The essentials in 30 seconds

AI in the dev workflow creates a new vector for secret leaks — and most teams do not protect against it

With the mass adoption of Copilot, Cursor and Claude Code, developers send code to external services every day. The problem: this code sometimes contains API keys, authentication tokens, database credentials or sensitive configuration files. According to a GitGuardian study (2025), 12.8 million secrets were exposed in public repositories in 2024 — a record. Development AI adds an extra leak channel: the prompts sent to the models.

The good news: with three simple measures — pre-commit hooks, prompt filtering, and centralized secrets management — you can secure your AI workflow without losing productivity.

The problem

Secret leaks are an old software development problem, but generative AI amplifies it in three new ways:

1. Prompts as a leak channel. When a developer asks Claude Code to "fix the bug in this configuration file", the configuration file — with its credentials — is sent to the model. Even if the AI provider does not store the data, it travels across the network and is temporarily in memory on third-party servers.

2. Generated code that hard-codes secrets. For convenience, AI sometimes generates code that includes configuration values inline: const API_KEY = "sk-...". If the developer commits this code without checking, the secret ends up in the Git history forever.

🔐

The average cost of a secret leak is 4.45 million dollars

IBM Cost of a Data Breach 2024 report. For SMBs, an API key leak can cost between 5,000 and 50,000€ directly (fraudulent billing on cloud services) and far more in reputational impact. The average detection time is 292 days.

3. Automation increases the attack surface. AI agents that execute commands (Claude Code, Devin, Cursor Agent) have access to the file system, environment variables and SSH keys. A poorly formulated prompt or a hallucination can lead the agent to read and transmit sensitive files unintentionally. This is a AI governance risk to anticipate.

The AI solution

Securing AI-augmented development rests on three complementary layers of protection.

🛡️

Layer 1: Prevention at the source

Prevent secrets from entering the AI flow. This goes through a pre-commit hook that scans every diff before commit (Gitleaks, detect-secrets), a rigorous .gitignore file (.env, *.pem, *.key), and a configuration of the AI tools to exclude certain files and folders from the context. Claude Code respects the .claudeignore file, Cursor the .cursorignore.

🔍

Layer 2: Continuous detection

Scan the Git history and the CI pipelines to detect secrets that escaped prevention. GitHub Secret Scanning (free on public repos, paid on private ones), GitGuardian (the most complete), or TruffleHog (open source) analyze every commit in real time and alert immediately in the event of a leak.

🔑

Layer 3: Centralized secrets management

Replace secrets in the code with references to a centralized manager: HashiCorp Vault, AWS Secrets Manager, Doppler or simply GitHub Actions Secrets. No plaintext secret in the code, the config files or the committed environment variables. Developers only have access to the secrets of their dev environment, not to those of production.

Implementation

Here is the three-step deployment plan to secure your augmented development workflow.

1

Install the prevention hooks (day 1)

Install Gitleaks as a pre-commit hook on all your repositories:

# Installation via the pre-commit framework
# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

# Create the exclusion files for the AI tools
# .claudeignore
.env*
*.pem
*.key
config/secrets/
infra/terraform/*.tfvars

# .cursorignore (same content)
.env*
*.pem
*.key
config/secrets/

Test by attempting to commit a fake secret. The hook must block the commit.

2

Scan the existing and clean up (week 1)

Run a full scan of the Git history of your main repositories:

# Scan the full history with Gitleaks
$ gitleaks detect --source . --verbose --report-path leaks.json

# Or with TruffleHog for remote repos
$ trufflehog git https://github.com/org/repo.git

For each secret found: revoke it immediately, regenerate it, and put it in a secrets manager. Do not just delete it from the code — it remains in the Git history.

3

Deploy centralized management (weeks 2-3)

Migrate to a secrets manager suited to your size: Doppler (the simplest for SMBs), GitHub Actions Secrets (free if you are on GitHub), or Vault (for mid-market companies with advanced needs). Update your code to read secrets from the environment variables injected by the manager, never from plaintext files. Document the procedure in the project's README. More information in our AI governance and risks guide.

Results

Secrets blocked before commit
99.5% — with the Gitleaks pre-commit hook enabled
Leak detection time
From 292 days to < 1 hour with continuous scanning
Plaintext secrets in the code
0 after migration to a centralized manager
Impact on dev productivity
Negligible — the pre-commit hook adds < 2 seconds per commit

Frequently asked questions

Do AI tools store the code sent in prompts?

It depends on the tool and the plan. GitHub Copilot Business and Enterprise do not retain prompts. The Claude API (Anthropic) does not use them for training. On the other hand, the free versions of ChatGPT and Copilot Individual may use the data to improve the models. Always check the terms of use and favor professional plans with confidentiality commitments.

How do you detect whether secrets have already leaked into the Git history?

Use tools like Gitleaks, TruffleHog or GitHub Secret Scanning to scan the full history of your repository. Be careful: deleting a commit is not enough if the repository has been forked or cloned. In the event of a confirmed leak, the only reliable action is to revoke and regenerate the affected secret.

Are .env files enough to protect secrets?

No. .env files are a first line of defense, but they remain in plaintext on disk and can be accidentally committed. The best practice is to combine .env (for local development), a secrets manager (Vault, AWS Secrets Manager) for production, and a pre-commit hook that blocks any commit containing a secret pattern.

For technical profiles

Comparison of secret detection tools (November 2025):

CriterionGitleaksGitGuardianTruffleHogGitHub Secret Scanning
Pre-commit scanYes (native)Yes (ggshield)Via custom hookNo
Git history scanCompleteCompleteCompleteRecent commits
Patterns detected150+ providers400+ providers800+ detectors200+ providers
CI/CD integrationGitHub Actions, GitLab CIAll CI/CDAll CI/CDGitHub only
Open sourceYes (MIT)FreemiumYes (AGPL)Free (public repos)
PriceFreeFrom $50/monthFreeFree (public) / $21/user (private)

Complete Gitleaks configuration for a TypeScript project:

# .gitleaks.toml
title = "Secret detection rules"

[allowlist]
  description = "Allowed files"
  paths = [
    '''.test.ts$''',        # No scan in tests
    '''.spec.ts$''',
    '''__mocks__''',
    '''fixtures''',
  ]

[[rules]]
  description = "Generic API key"
  regex = '''(?i)(api[_-]?key|apikey)s*[:=]s*['"][a-zA-Z0-9]{20,}['"]'''
  tags = ["api-key"]

[[rules]]
  description = "JWT token"
  regex = '''eyJ[a-zA-Z0-9_-]{10,}.eyJ[a-zA-Z0-9_-]{10,}.[a-zA-Z0-9_-]{10,}'''
  tags = ["jwt"]

[[rules]]
  description = "Connection URL with credentials"
  regex = '''[a-zA-Z]+://[^:]+:[^@]+@[a-zA-Z0-9.-]+'''
  tags = ["connection-string"]

Metrics to track: number of secrets detected in pre-commit per week (target: decreasing), secret rotation time after a leak (target: < 1 h), repo coverage by scanning (target: 100%), number of plaintext secrets in the code (target: 0).

Related articles