To enhance security and prevent accidental exposure of sensitive credentials to AI systems, we should block access to environment files containing credentials.
Details
Block access to *.env files
Block access to *.env.local files
Block any other files that typically store credentials or secrets
Security Impact
Prevents accidental leakage of credentials to AI systems
Reduces risk of unauthorized access to sensitive information
Aligns with security best practices for handling environment variables
Related Items
Consider adding similar protection for other credential storage files
Document the blocked file patterns in security documentation
.cursorignore file defines which files should be excluded from code base indexing for reference purposes. However, even if files are listed here, AI can still read them. It’s crucial to prevent AI from accessing credentials and confidential information.
100% agreed, this is absolutely critical to being able to use cursor to build real production software
.cursorignore does not seem to work very well. I’ve been very diligent to add .env there, but I’ve noticed multiple instances of the cursor agent writing to .env and even adding .env to the context in the context file picker.
Custom instructions are sent before the agent begins processing, so they are effective safeguards if they follow the rules. However, this should be the default behavior.
Theory and practice differ. I could easily check the traffic using a proxy. It is sent via plaintext to the count token endpoint (and probably in binary form in several other requests, but it seems to use protobuff or something similar for communication).
Here is me triggering a Chat (which automatically added the .env file as context)
As a corollary, there should be a secure alternative for defining and injecting environment variables or secrets into the cursor agent, entirely on the client side. This would maintain security while allowing the cursor agent to function effectively in agent mode when executing commands.
Environment files like .env and .env.local contain sensitive information such as API keys and database credentials. Allowing AI tools to access these files by default poses significant security risks, including potential unauthorized access and credential leakage. To mitigate these risks, it’s essential that Cursor’s default settings prevent AI from reading such files. Relying solely on users to configure .cursorignore files isn’t sufficient, as this approach can lead to accidental exposure of confidential data. Implementing a default block on access to these credential files aligns with security best practices and enhances overall trust in the platform.
I want to expand on problematic scenarios that could lead to secrets being leaked, as long as those files aren’t blocked by default:
A user accidentally opens the wrong folder or one that already contains sensitive information.
A Git repository contains sensitive data that the user was unaware of (e.g., a private company-internal repo created by a colleague).
A Git repository unexpectedly includes relative symlinks to other critical directories (imagine a compromised library creating a symlink to ~/.ssh).
A script, an attacker, or even the user—intentionally or accidentally—runs cursor someDir in the shell.
The user is simply unaware of this behavior or hasn’t been properly informed.
I strongly believe this isn’t a matter of perspective—people make mistakes, and good security concepts should account for that by making it difficult to make such mistakes in the first place.
Ultimately, all it takes is a brief moment of failing to manually ignore these files for them to be transmitted, at which point they should be considered compromised.
I also want to highlight that while Cursor states these files are not stored in private mode, the fact that they are transmitted at all is already a security risk. Even if one trusts Cursor to handle these files responsibly, other attack vectors, such as man-in-the-middle attack, still exist.
Lastly, the benefits of processing these files for the overall experience are negligible. Most frameworks and languages already reference .env keys in their codebase through constants, making this feature largely unnecessary
