Secrets Management for AI-Assisted Development

New here? This article is part of our AI development series. If you are setting up AI-assisted coding for the first time, start with our guide to getting started with Claude Code and then come back here to lock down your secrets.

Topic	When to Use	Key Tool
Pre-commit scanning	Every repository, from day one	gitleaks
.env templates	Any project with environment variables	.env.example
Vault integration	Production and staging environments	HashiCorp Vault / AWS SM
CI/CD scanning	All repositories with CI pipelines	GitHub Secret Scanning
Key rotation	All long-lived credentials	Vault auto-rotate

Why AI Tools Make Secrets Leaks Worse

AI coding assistants are brilliant at generating boilerplate, refactoring functions, and writing tests. They are also brilliant at leaking your secrets. Not out of malice — out of pattern matching. When an AI tool sees a database connection string in your context window, it will happily reproduce that pattern in the code it generates. When it writes a Terraform module, it may hardcode the API key it found in your environment rather than referencing a variable.

The traditional secrets hygiene advice — “do not commit credentials” — still applies, but it is no longer sufficient. AI-assisted development introduces entirely new attack surfaces that most .gitignore files and code review processes were never designed to catch.

In 2025, GitGuardian reported that over 12.8 million new secrets were exposed in public GitHub repositories. With AI tools now generating a significant portion of committed code, that number is accelerating. The good news: every one of these leakage points has a practical defence. Let us walk through them.

The Five Leakage Points

Understanding where secrets leak is the first step to stopping them. Here are the five most common leakage points in AI-assisted development workflows:

1. Context window ingestion. Tools like Claude Code, GitHub Copilot, and Cursor read your project files to understand context. If your .env file contains live credentials and is not excluded from the AI’s context, those credentials become part of the model’s working memory. From there, they can appear in generated code, logs, or suggestions.

2. AI-generated code. When an AI assistant writes a new integration — say, connecting to Stripe or AWS — it may generate code with hardcoded API keys rather than environment variable references. This is especially common when the AI has seen real keys in the context window and reproduces the pattern.

3. MCP configuration files. The Model Context Protocol (MCP) lets AI tools connect to external services. These configuration files often contain OAuth tokens, API keys, and database connection strings in plaintext. They frequently end up in version control because developers treat them like any other config file.

4. AI chat history. Developers paste credentials into AI chat prompts when debugging. “Why is this API key not working?” followed by the actual key. These conversations are logged, sometimes synced to cloud services, and rarely treated with the same security posture as production systems.

5. Generated infrastructure as code. AI tools generating Terraform, CloudFormation, or Pulumi templates may embed secrets directly in terraform.tfvars, parameter files, or resource definitions. Unlike application code, IaC files often bypass the usual code review scrutiny.

Layer 1: Pre-commit Hooks

The single most effective defence against secrets leaks is a pre-commit hook that scans every commit before it reaches your repository. If a credential slips into your staging area, the hook blocks the commit and tells you exactly where the problem is.

Setting up gitleaks takes about two minutes. Install it, create a configuration file, and wire it into your pre-commit hook:

Next, create a .pre-commit-config.yaml in your repository root:

Install the hook and test it:

For teams using Claude Code specifically, add rules to your CLAUDE.md file to instruct the AI never to read or output the contents of .env files:

Layer 2: .gitignore and Environment Templates

A properly configured .gitignore is your second line of defence. It should exclude every file that could contain secrets:

Alongside your .gitignore, always provide a .env.example file with placeholder values. This documents what environment variables your application needs without exposing actual credentials:

Layer 3: Vault Integration

For production environments, environment variables alone are not enough. A secrets vault provides centralised management, access control, audit logging, and automatic rotation. The two most common options are HashiCorp Vault and AWS Secrets Manager.

With AWS Secrets Manager, you reference secrets by name rather than storing values in your deployment configuration:

The critical principle: your code references a secret name, never a secret value. Even if the AI generates this code and it ends up in a public repository, the secret name alone is useless without access to your AWS account.

Layer 4: CI/CD Scanning

Even with pre-commit hooks, mistakes happen. A developer might bypass the hook with --no-verify, or a credential might be in a format that the local scanner does not recognise. CI/CD-level scanning provides a server-side safety net.

GitHub Secret Scanning is free for public repositories and available with GitHub Advanced Security for private ones. It scans every push for known secret patterns from over 200 service providers and can automatically revoke detected tokens with supported partners.

For a broader approach, add a gitleaks step to your CI pipeline:

This runs on every push and pull request, scanning the full git history for secrets. If it finds anything, the workflow fails and the PR cannot be merged.

Layer 5: Rotation Policy and Monitoring

The final layer acknowledges reality: despite your best efforts, a secret will eventually leak. The question is not if but when — and when it happens, how quickly does the leaked credential become useless?

Automatic rotation means that even if a key is exposed, it expires before an attacker can exploit it. AWS Secrets Manager supports automatic rotation for RDS databases, Redshift clusters, and other AWS services. For third-party API keys, you can write a Lambda function that rotates the key on a schedule:

Combine rotation with monitoring. Set up alerts for:

• Unusual API key usage patterns — spikes in requests from unfamiliar IP addresses
• Secret access from unexpected services — if your web server’s secret is being read by an unknown Lambda
• Failed authentication attempts — someone trying old, rotated credentials
• GitGuardian or GitHub alerts — immediate notification when a secret appears in a commit

Putting It All Together

Secrets management for AI-assisted development is not a single tool — it is a stack. Each layer catches what the previous one missed:

1. Pre-commit hooks catch secrets before they enter your repository
2. .gitignore and templates prevent secrets files from being tracked in the first place
3. Vault integration removes the need to store secrets in code or config files
4. CI/CD scanning provides a server-side safety net for anything that bypasses local checks
5. Rotation and monitoring limit the blast radius when a leak does occur

Start with Layer 1 today. It takes two minutes to install gitleaks and will catch the majority of accidental leaks. Then work your way up the stack as your project matures. The goal is not perfection — it is defence in depth, so that no single failure leads to a breach.

If you are using Claude Code, the most impactful step you can take right now is adding a secrets policy to your CLAUDE.md file. Four lines of instruction can prevent the AI from ever reading or reproducing your credentials. Combine that with a pre-commit hook and you have eliminated the two most common leakage vectors in under five minutes.

Related: For more on configuring Claude Code’s behaviour through CLAUDE.md, see our guide to mastering CLAUDE.md for project-wide AI development. For a broader look at AI development security, read secure AI coding with Claude Code.