Thanks for the response!
I actually build some cursor-rules that have helped to prevent this going forward which I think would be good to include out of the box.
WHAT I’M PROPOSING
Include secrets safety protections as default Cursor rules that:
1. Block dangerous commands (cat .env, echo $SECRET) with clear error messages
2. Warn on risky patterns (hardcoded keys, fallback values like process.env.KEY || ‘sk_test_…’)
3. Force .gitignore verification before git add to prevent accidental commits
4. Provide escape hatch: cursor.secretsProtection: false for users who need it
WHY THIS BENEFITS CURSOR
Zero-day protection for new users — prevents embarrassing security incidents before they happen
Competitive positioning — Cursor becomes known as security-conscious by default (users appreciate this, competitors don’t have it)
Prevents negative word-of-mouth — better to be proactive than reactive to “I accidentally exposed my API key to an AI”
Reduces support burden — stops the “oops I exposed secrets” support tickets
HOW I BUILT THIS
Secrets Safety Rules (in my .cursorrules):
- NEVER run: cat .env, echo $SECRET, secret-viewing commands
- NEVER run secret-generating commands via Shell tool (output enters AI context)
- NEVER hardcode secrets or use fallback values
- ALWAYS add secret files to .gitignore BEFORE creating them
Public Content Security (in .cursor/rules/public-content-security.mdc):
- Prevents accidental exposure in open-source repos, docs, READMEs
- Blocks Firebase IDs, storage buckets, Cloud Function URLs, collection names
- Forces .gitignore verification before git add
PROOF IT WORKS
These rules have caught several near-misses:
- Agent tried to cat .env to check a variable name → blocked
- Agent tried to log Firebase secret to verify it loaded → blocked
- Agent created a repo and tried git add . before .gitignore was complete → blocked
OPEN SOURCE RELEASE
I’m releasing these as part of a broader Cursor Toolkit repo (rules, skills, and workflows for production-grade AI-assisted development). The secrets safety rules are one component, alongside git workflow best practices, model selection guidance, cross-platform development patterns, and proposal writing frameworks.
Feel free to incorporate these rules into the default agent system prompt or ship as default .cursorrules templates. Happy to collaborate on adapting them for broader use!
Thanks!