Comment by heavyset_go
15 hours ago
Another way to look at this is that you're giving away all of your source code as context, and probably a lot of things you don't necessarily want to share, if you aren't using self-hosted models.
Especially with agents that slurp up files, have access to databases, etc. You're literally giving access to your computer, your network and your data to third parties and letting them run code.
During development you don't use prod data, though. So I don't see much problem here, even if I'm developing something where I would store sensitive data later.
(If there is a bug though which I would want to debug and if I were not a developer, then your concerns are more valid)
> During development you don't use prod data, though.
I’ve seen projects where testing is done in prod and also projects where API keys for some external services (e.g. Mapbox) are shared across prod and dev. Or cases where credentials end up in Git repos (edit: wrote GitHub originally, but meant typically non-public repos on any platform) due to ease of use and how inadequate secret management solutions can be.
Luckily that’s not the majority of projects, but I bet it happens a lot more elsewhere. Definitely a bunch for your average outsourced/freelance/scrappy/non-funded project.
Whether anyone will actually use your secrets or even code that’s sent to these large AI shops, though, that’s another question. You might as well question using GitHub cause it’s owned by M$.
honey pot that shit. attackers, security companies, GitHub themselves, are all crawling GitHub for leaked credentials and will tell you that they've been leaked. GitHub very much knows what a GitHub API key looks like. So you stick a GitHub API key with the least useful permission you can think of into your secrets file. If that file ever gets uploaded to GitHub, they'll cancel the key and email you about it, so then you know the rest of the keys in that file have been leaked as well.