Hey everyone, ran into a concerning issue today and wanted to get your thoughts.
I was writing a Terraform module for an S3 bucket and added a comment like `# Store the access key here for the app...`. Before I could finish, Cursor's autocomplete aggressively suggested an actual-looking AWS key pair (`AKIA...` followed by a fake secret key). 😳 This is a huge security risk if someone accidentally accepts it and commits it, even as a comment.
It seems like Cursor's training data includes a lot of code snippets with placeholder keys, and it's a bit too eager to suggest them. I love the tool, but this is one area where its helpfulness becomes a genuine hazard.
Has anyone else encountered this? I'm looking for a way to configure Cursor to **never** suggest strings that look like API keys, secrets, or passwords, especially in comments. I checked the settings but couldn't find a specific rule for this.
A temporary workaround I'm using is being super explicit in my comments, like `# The access key will be stored in AWS Secrets Manager`, which seems to steer it away. But I'd prefer a solid solution.
Maybe there's a way to tweak the `.cursorrules` file? Something like:
```json
{
"security": {
"preventSuggestions": [
"AKIA[0-9A-Z]{16}",
"sk_live_[0-9a-zA-Z]{24}",
"ghp_[0-9a-zA-Z]{36}"
]
}
}
```
Would love to hear if the community has any strategies or if the Cursor team has addressed this. Safety first!
Infrastructure as code is the only way
Yeah, that's a scary one. I've seen similar issues where it suggests placeholder API keys or fake credentials from training data, especially when you're drafting comments or documentation.
Your workaround is clever, but you shouldn't have to write comments defensively. The .cursorrules idea is interesting. A pattern-matching rule to suppress completions that match known secret formats (like the AKIA prefix for AWS) could be a solid feature request for the team.
For now, you might want to submit this as a security concern directly through Cursor's feedback channels. When a tool's helpfulness crosses into creating a genuine risk, it usually gets prioritized.
Totally agree, that's a major red flag! It's surprising there isn't a built-in guardrail for that yet. Besides your workaround, I've found that setting the autocomplete suggestions to be less aggressive can help a bit as a stopgap - sometimes it's the speed of the suggestion that trips you up.
Have you tried reaching out on their Discord? The devs are pretty active there for bug reports and feature requests. Framing this as a security fix might get it some traction.
Automate the boring stuff.
The speed is absolutely a factor. I've noticed the same thing when writing configuration examples. It's not just keys, either - placeholder database URLs with embedded credentials can pop up just as fast.
Turning down the suggestion aggressiveness helps, but it's a global setting that punishes legitimate completions. A targeted filter for strings matching secret patterns (AWS keys, GitHub tokens, connection strings) would be far more precise.
Discord is the right venue. I've reported a few similar hallucination issues there, and they were logged. Framing it as a security fix, not just a nuisance, is key.
Your fancy demo doesn't scale.
Framing it as a security fix is optimistic. It's a training data problem they'd have to actively scrub, and they have zero incentive. The placeholder keys exist because people commit them, and Cursor trained on those repos.
It's a liability they'll only address after a headline-making breach. Until then, it's a "user beware" feature.
Your stack is too complicated.