From last one week we found sudden increases in the API usage in the name of ‘Other Models’ . which is not made by us. which cause almost 600$ in one week. Can anyone help us to solve this issue?
2 Likes
I can’t help solve it, I’m afraid, but if it helps I can report that we’ve seen exactly the same thing on our account: sudden surge in API requests to a variety of high-cost GPT 4/4-turbo/4 Preview models which we don’t use in any of our applications. Because of this I’m assuming that one of our API keys has been compromised so the only thing I can recommend is the standard advice in case of a breach: delete the compromised key, set up MFA for all users, log out of all devices.
I would be keen to know if other users have seen the same, though, as the more troubling question for us is how was the key compromised?
1 Like
Thanks, I think that’s good advice - it seems that it was an old user key that was compromised for us so we have removed all of these and instantiated new ones. That said, I also agree that it’s a little alarming that there’s been no communication from OpenAI about this vulnerability (if it is indeed one). We’ve not stored our keys anywhere other than as environment variables in our production environment which is as secure as it can be and shows no sign of breach, so I’m struggling to see how this is an issue on our side of the fence.
Welcome @lakshmanan.k
Have you/anyone in your org shared the API key with a third party?
Hi @sps! Thanks for your message. I’ve been doing some digging and the curious thing is that the API key that has been compromised is an older user one that was only ever used and stored locally for testing by a single user - it was never shared nor even stored in an online environment (even as an environment var). It looks to me like it can only have been intercepted in transit or the cipher itself was cracked.
And when you get a new key now, it is much longer…
One can decide for themselves that all existing keys, including now harder-to-discover legacy user keys in billing, must be cancelled and replaced with newly-generated ones.
You would not be the only one to have made such speculation, but you might not suffer having your posts about it deleted silently.
Hi everyone, Ive been reading this thread as I too have had a really big increase in cose on my api.
I saw someone saw generate a new api key … could I ask anyone, if I do this, will that mean my users will loose their chats or data?
I have all their data saved on mongo and we use clerk for user verification …
Hello, that is an excellent question.
An API key is simply an authentication mechanism. It will land you into the same scope as other API keys within the same container, whether that container is legacy owner-based keys, or project keys. Each of those “containers” can have multiple keys that serve the same purpose.
If you are using chat completions, then there is no storage of user data on the provider’s services. You are the one maintaining a conversation history and user data, and you can just as easily have a conversation be continued with selection of a different model, or even continue with a different AI provider.
If you are using Assistants, then conversations are stored in a server-side thread. You associate the thread ID with the user and maintain that connection yourself.
Projects should have scoping, a higher level of separation of user data. It would be important that if you are making your Assistants calls in one project, with user data (uploading files and images for a user, keeping threads of user conversations), that the new API key is also created in the same project as was previously used. The server-side information will not be lost, but misconfiguration by using the wrong project’s keys and wrong project headers in requests may prevent proper operation until you correct that situation. (in practice, the scoping and containment of user data within a project is in a preliminary state, not announced or promised).
So you should have no fear implementing new keys, ensuring that you have not forgotten to update any developers or applications with their new key, and then remove the old ones.
Regular rotation of keys, just like passwords, is a good idea to make any data leaks that could have happened obsolete.