My AI tool config file got exposed. What should I do?
Files like CLAUDE.md, .cursorrules, .cursor/rules, .aider.conf.yml and .windsurfrules configure AI coding assistants. They often contain system prompts that describe your internal architecture, business logic, coding conventions — and sometimes API keys or credentials embedded directly in the instructions.
Open the file, scan for credentials, remove from web root — in that order.
Even if the file contains no explicit secrets, the system prompt itself may reveal proprietary business logic or architectural decisions you'd rather keep private. Treat the exposure as a leak of your internal documentation.
// the 60-second version
- Read the file carefully — look for API keys, tokens or credentials in the instructions.
- Rotate any credentials found immediately.
- Remove the file from the web-accessible directory.
- Add AI config files to
.gitignoreand web server deny rules.
01Understand what these files contain
AI tool configuration files serve as persistent instructions for coding assistants. Depending on how your team uses them, they may contain:
- System prompts — instructions describing how the AI should behave, what it should or shouldn't do, naming conventions, preferred libraries. These reveal how your codebase is structured.
- Internal architecture details — descriptions of database schemas, API designs, service dependencies, or deployment environments.
- API keys or tokens — some teams embed credentials directly in the instructions so the AI can reference real endpoints. This is dangerous.
- Business logic — rules about how features work, what data is processed, or how decisions are made. This is proprietary information.
System prompts are increasingly targeted by attackers. A detailed CLAUDE.md describing your internal systems gives an attacker the same context a new developer would get in their first week — helping them identify likely attack vectors, understand what data is stored where, and craft more targeted exploits.
02Search the file for credentials
Open the exposed file and scan it carefully for anything that looks like a credential:
# search for API keys, tokens, passwords in the file grep -iE "(api[_-]?key|token|secret|password|bearer|sk-|pk-|ghp_|glpat-)" CLAUDE.md # also check for URLs with embedded credentials grep -E "https?://[^:]+:[^@]+@" CLAUDE.md
If you find any credentials, rotate them immediately before doing anything else — assume they have already been read.
03Remove the file from the web root
The file should never be in a directory served by your web server. Move it to a location above the web root, or add a deny rule:
location ~* ^/(CLAUDE\.md|\.cursorrules|\.windsurfrules|\.aider\.conf\.yml)$ { deny all; return 404; } location ~ /\.claude/ { deny all; return 404; } location ~ /\.cursor/ { deny all; return 404; }
<FilesMatch "^(CLAUDE\.md|\.cursorrules|\.windsurfrules|\.aider\.conf\.yml)$"> Require all denied </FilesMatch> <DirectoryMatch "\.(claude|cursor)"> Require all denied </DirectoryMatch>
04Add to .gitignore to prevent future exposure
AI config files often contain information specific to your development environment and should generally not be committed to version control at all — and certainly should not be deployed to production servers:
# AI tool configs — may contain sensitive prompts or credentials
CLAUDE.md
.cursorrules
.windsurfrules
.aider.conf.yml
.aider.chat.history.md
.claude/
.cursor/
Note: if you intentionally share CLAUDE.md or .cursorrules as part of an open-source project, ensure they contain no credentials and only the information you're comfortable making fully public.
05Review server access logs
Check how long the file was accessible and whether it was downloaded:
If the log shows requests from IPs you don't recognise, assume the file contents have been read in full. Rotate any credentials and review what internal information was disclosed.
Was this guide useful?
These playbooks are free to read and share. If a heads-up ever saved you a bad week, you can say thanks — or jump into the other guides.