Draw a network diagram of your application and where all code and data lives and gets deployed/transferred.
If the access key at any point is on a wire that heads towards a user, for any kind of request, then you will get a compromise.
This might be as part of a debugging log, as part of an error message (which can be deliberately provoked by attackers!) as part of downloaded configuration flags, and so on.
If none of that is happening, and you still see compromises, then someone inside your organization is doing it.
graph TD
subgraph Client ["Client Application"]
CID[("Customer ID\n(stored in client)")]
end
subgraph Server ["Backend Server"]
OAK[("OpenAI Key\n(stored in server)")]
end
subgraph OpenAI ["OpenAI API"]
API[("API Endpoints")]
end
Client -->|Customer ID Token| Server
Server -->|OpenAI Key| OpenAI
classDef encrypted stroke-dasharray: 5, 5;
class Client,Server,OpenAI encrypted;
Also, make sure that you’re not hardcoding the API key in your code and pushing it to GitHub. Even if the code is inaccessible to the client, your API key will be revoked automatically if it’s present in any code on GitHub.
Every time we’ve had our API key revoked it’s been because someone checked it in to GitHub and was found by a code scanner. If you’re storing your keys in something like a . env file make sure it’s in your .gitignore file
Alright, we’ve included the Facebook AI key as an alternative, which eliminates any revocation issues.
What specific information do you need from me to confirm that this is an OpenAI problem?
I’m here to seek a solution or explore other options for utilizing the GPT key without facing revocation. My aim is to find a solution. Given GPT’s superior quality, it’s our preference for serving our customers with GPT.
You could try copying down on paper, instead of copying to clipboard, in case your development PC is compromised and there is maybe regex sniffing your clipboard for sk-…
Or your server has a vulnerability where somene can read the env vars