Documentation

How AIProxy works

To use AIProxy you add your OpenAI API key through our dashboard, but we don't actually store the key on our servers. We encrypt the key and store 1/2 of that result in our backend and give the customer the other 1/2 to send up with requests to AIProxy. We marry the two pieces and decrypt the key, forwarding that onto OpenAI.

This technique addresses a few security concerns:

1. If someone sniffs the customer's AIProxy request from the network, there is no way for the attacker to use the information in the request headers to derive the customer's OpenAI secret key. Anything that goes over the network is fair game for an attacker to view in plaintext. E.g. an attacker could install your iOS app on their own phone and then MITM themselves to inspect network requests of your app. So we assume someone is looking, and take precaution that the data that they see is as useless as possible.
2. By splitting the encrypted key into two parts, and storing them separately (one on the backend, and one in your iOS app), we disincentivize attacks on AIProxy itself. The alternative, where our database has all the information it needs to construct openai secret keys, would make for a lucrative target for attackers. If someone were able to get in, they could get a whole bunch of openai secret keys.
3. It gives customers the assurance that no one within AIProxy can look at their OpenAI secret keys, because we don't actually have them in our database.

That's one piece of protection, and prevents anyone from sniffing your OpenAl key from your iOS app completely. However, an attacker can still grab your AIProxy headers and abuse your AIProxy endpoint. So to combat that we send up 1 time use devicecheck tokens. We check the device check token against Apple's servers to ensure that it's from a legit device running your app, and also check against our DB to make sure the token hasn't been used before. If the token passes both of those checks then we fulfill the request.