I just ran into a concerning scenario. I’ve been trying to debug an issue communicating with TwelveLabs, and we of course have an API key for that. All files that might contain sensitive keys, even dev keys, are included in our .cursorignore files. So the agent is not allowed to edit them…for example .env, at least not directly (they certainly find way AROUND that, though!)
Well, as part of troubleshooting this issue accessing the TwelveLabs API, I suddenly noticed the agent printed out the full key. I never gave the key to the agent, it is only in our files excluded by .cursorignore, I only log out masked versions into our logs, so the agent should not have been able to get ahold of the full key. Yet, it did…
So I asked it why….and this greatly concerns me:
If a file, or a glob, is in .cursorignore, why is the agent allowed access to it, just because it is open in an editor tab?? I edit my environment files, directly, by hand. So, OF COURSE they are going to be open in editor tabs at times. However I have them in my .cursorignore for a very darn good reason: SECURITY! Even though we have privacy enabled, my key…and now I wonder HOW MANY keys, and from which environments (!!), have been sent to who knows how many LLMs over the last 10 months, because of this loophole. I don’t know how that might compromise them, but they do feel compromised now…they have been run through a model, possibly many different models, and I don’t know how strictly each one treats “privacy requested” modes or requests, and how much these keys might be ending up embedded into some LLM somewhere, possibly to be regurgitated at some point…?
I don’t know if this is necessarily a bug…it is certainly a loophole that I am gravely concerned could potentially compromise our security. I do not EVER want any of our full keys to be accessible by the agent. Perhaps .cursorignore isn’t necessarily intended for this? In fact, despite .cursorignore, there have been numerous times, especially in the last month to month and a half (like so many other weird issues with Cursor lately), where the agent has even been able to EDIT my .env files. It blew away my .env and replaced it with a new file that was .env.[something] (a specific name not explicitly listed in our .cursorignore) that the agent was able to write, then it issued a command to copy that file over my .env file. (FWIW, I have since updated our rule to include .env.* to prevent this from happening again in the future…although, I honestly don’t know if it is sufficient, given the compromise was due to a terminal command that was executed, not an internal cursor tool usage like read_file…)
So perhaps there needs to be a more explicit way to FULLY, WHOLLY and COMPLETELY DENY the agent access to certain files, period, no matter what, no matter how they may try to end-run around the rules. Even to the point where cursor checks terminal commands to make sure they are not trying to access or otherwise reference files listed in…say…a .cursordenied file or something like that. Or maybe this IS the intended purpose of .cursorignore and there are just loopholes that need to be closed?
Some files, some data, is just not meant for the agent’s consumption, period. This is a concerning loophole that I think needs to be addressed. It may not necessarily strictly be a bug, but it is an issue.