Security Issue: Debug Mode Credential Exposure (Sonnet 4.5)

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Security Issue Report: Debug Mode Credential Exposure
Model: Claude Sonnet 4.5
Date: 2026-03-4
Severity: High

Issue
During a credential rotation task, the AI agent generated and displayed a production secret in the chat UI, directly contradicting the security practices it was implementing.
Context: User was removing hardcoded credentials from .cursorrules (which gets sent to AI providers) and setting up proper secret management for production Cloud Functions.
What happened: Agent executed openssl rand -base64 32 via Shell tool and displayed the output in chat, exposing the newly generated secret to:
Anthropic’s servers (logged)
User’s chat history (persistent)
Anyone with Cursor access
The Problem
Agent treated existing vs. new credentials differently:
Existing credentials: Correctly moved to .env.test, never shown in chat
New credentials: Generated via Shell tool, displayed in chat output
This recreated the exact exposure risk the task was designed to prevent.
Expected Behavior
Agent should have instructed user to run openssl rand -base64 32 in their own terminal, never executing secret-generation commands through observable tools.
User Observation
“You seem to be making a lot of security lapses when you’re in debug mode that you weren’t necessarily making in other modes.”
Hypothesis: Debug mode’s focus on tool execution and runtime evidence may override security judgment about what should/shouldn’t be executed observably.
Recommendations
Block secret-generation commands (openssl rand, password generators) from Shell tool execution in chat context
Apply “never show credentials” rules uniformly to both existing and newly generated secrets
Add pre-execution security check: “Will this command output contain secrets/credentials?”
Review debug mode instructions for security blind spots
Impact
User caught the error before using the exposed secret. No actual compromise, but the pattern is concerning—agent violated its own security guidance within the same conversation that established it.

Steps to Reproduce

  1. Start a conversation in Debug Mode (Cmd+Shift+P → “Debug with AI”)
  2. Work on a task involving credential/secret management
  3. Ask the AI to generate a secure random password or secret
  4. Observe: AI uses Shell tool to run openssl rand -base64 32 and displays the output in chat

Expected Behavior

Agent should instruct user to run secret-generation commands in their own terminal, never executing them through observable Shell tool. Newly generated secrets should be treated with same “never show in chat” rules as existing credentials.

Operating System

MacOS

Version Information

Version: 0.42.3

For AI issues: which model did you use?

Claude Sonnet 4.5 (Debug Mode)

Additional Information

Issue occurred during credential rotation task. Agent correctly implemented security measures (moving credentials to .env.test) but then violated those same principles by generating and displaying a production secret via Shell tool in the same conversation. User intervention prevented actual compromise.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

3

Hey, thanks for the detailed report. This is a valid concern.

What’s happening here is that the agent’s Shell tool runs a command, and the output becomes part of the conversation context, which gets sent to the model provider. This applies to any terminal output, not just secrets, but for secret generation it’s especially risky.

A couple of things worth noting:

  • By design, terminal commands require your approval before execution. The security docs cover this: Agent Security | Cursor Docs. The expectation is that you review each command before approving.
  • That said, you’re right that the agent should be smarter about not offering to run secret-generation commands through the Shell tool in the first place.

Workaround for now: You can add a rule in your project’s .cursor/rules file like:

Never execute commands that generate secrets, passwords, or cryptographic keys (e.g., openssl rand, ssh-keygen, etc.) via the shell tool. Instead, instruct the user to run these commands in their own terminal.

This will guide the agent’s behavior for your project.

I’ve flagged this with the team. No timeline on changes, but your report helps with prioritization.

Let me know if the rules workaround helps.

4

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!

6

Hey, great approach. I’m glad the rules workaround worked, and that you expanded it into a full set of rules.

Your suggestion to enable secrets safety protection by default makes sense. I passed the feedback to the team. I can’t promise specific timelines, but detailed suggestions like this help with prioritization.

If you publish the Cursor Toolkit repo, drop the link here. It might be useful for other users.

7

Thanks for passing this along to the team - just don’t want people to not realize something happened especially now that automation is launching. As things become more and more abstracted away from the user, these security issues can just slip through the cracks.

I’ll share the repo once I load it - shooting to do so later today!

8

Hi Dean, as promised, here is the Cursor Toolkit - it’s open source and useable for anyone.

Feel free to leverage for out-of-the-box features. It’s been super helpful for me, especially as I build multiple projects for both security and efficiency, and to do a lot of other things that require writing in my style.

Cheers!