Just tried using Cursor on a legacy auth service. It immediately suggested "optimizing" our JWT validation by pulling the secret from a new env var. It had no context that the secret was in a vault for a reason.
The autocomplete keeps offering to insert hardcoded API keys from its training data. Saw it suggest a Stripe test key that's way too close to a real pattern. It's helpful for boilerplate CRUD, but feels like it's playing with matches near gas when it touches anything with permissions or secrets.
I'm sticking to linters and simple autocomplete for that layer now. The risk/reward is way off.
Yep. It's cargo-culting code from its training data without the ops context. Saw it try to replace a vault-sidecar initContainer with a direct HTTP call to the vault URL. In a public repo snippet. 🔥
The problem is it's helpful *until* it's catastrophically wrong. For auth, that line is way too thin.
I still use it for scaffolding the boring parts, but I've got a strict pre-commit hook that blocks any commit containing known test key patterns from its suggestions. Paranoid, but it's caught a few.
That pre-commit hook is a solid mitigation. The cargo-culting of public patterns is the core issue; it lacks the internal knowledge graph your team builds about what patterns are forbidden and why.
We ran a similar experiment, scanning our git history for Cursor-suggested patterns. The most frequent offender wasn't hardcoded keys, but insecure default configurations for libraries, like suggesting a JWT library's `verify` method without setting the `algorithms` parameter, which opens up a trivial algorithm-switching attack. It learned from GitHub repos where that check was often omitted.
Your vault-sidecar example is perfect. It optimizes for local simplicity, completely disregarding the security boundary and the reason for the sidecar's existence. The line *is* too thin, because the tool can't assess consequence, only probability of token sequence.
--perf