Is this the solution to BYOK?

Hi,
I came across some posts that adress the BYOK problem, but each come with its own limitations and implications.
Here’s a different solution that I think can standardize how BYOK apps handle keys safely for both parties.

Do check it out here, Feedback is most appreciated and welcome.
Sorry I cant include links in this :frowning:
Its open source and available on Github at “/glueco/gateway”

I will update this post when I am able to add links.

Thanks and good luck.

1 Like

Gateway is a self-hosted middleware ( fork and deploy pull from vercel ) that keeps keys on your infrastructure.

Mechanism: Uses a cryptographic Proof-of-Possession (PoP) flow. Apps get a short-lived pairing string, never the raw key.

Controls: Enforces rate limits, quotas, and model restrictions (e.g., “only allow gpt-4o-mini”) that provider dashboards don’t offer per-app.

Welcome to the forum.

This seems like an interesting project for self managed backends, but I wouldn’t sell it as a BYOK solution, it looks more like a backend component.

Anything that stores the user keys is a risk, and if that goes out of the user’s own device the risk increases as it adds in the server vulnerabilities. Also, the main issue is not handling keys in itself, I think most users are not willing to sign up for creating and managing their own “developer” api keys.

The only solution I see that would improve security is if each key provider were to allow their own “sign in with ChatGPT account”, this way security is handled directly with no api key bein shared at all.

3 Likes

Great points.

You’re absolutely right, a native “Sign in with OpenAI” (OAuth) would be the dream solution. But until that exists, we are stuck with the current BYOK model, which has some major flaws.

Right now, I have to trust every single app owner to store my raw key securely. Plus, if I use 5 different AI tools, I’m pasting the same key into 5 different places. That is a massive attack surface; if just one of those apps is compromised, my key is leaked, not to mention you can’t generally limit per app you added the key into, no limits on what it does with it.

This Gateway is definitely a backend component, but one the user owns, currently it’s made so that you can easily deploy it to Vercel, it’s a nextjs app, with a proper UI, it’s designed so that you can add plugins ( a plugin per resource ), which are ideally a plug and play into the app, which I hope can be made in the future so that it is doable from the within the app.

The goal is to stop scattering raw keys across the web. I host the Gateway myself, so I only have to trust my infrastructure, I set the rules. The apps just get a temporary, limited connection rather than the master key.

Agreed that this isn’t for the average user, but for power users and devs, but that’s a given with BYOK model, but maybe it can bridge the gap, I think there’s many possibilities this could add and improve on. it’s a way to centralize control rather than handing out admin keys to every new tool we try.

Further, I think maybe , a big maybe, this infrastructure could potentially be the backbone of data decentralization, each use has to host their own data. :grinning_face_with_smiling_eyes: But that’s something else.

I see this became a little long, apologies for that.

1 Like

Thanks for the detailed insights, and by no means I don’t want to discourage you as I see value in your idea itself, its just that I thought it might serve to solve a different problem.

I don’t know if you have heard of openrouter, but if you are afraid of what BYOK apps might do to your key, they allow you to set daily limits on usage per key (and other limits), without exposing the real api keys. Plus they support a huge variety of providers and follow an industry standard, even openai allows you to use them for conducting evals with other models.

Anyway, I wish you good luck with your project and thanks for sharing it with us.

Thanks for the kind words, I’m actually looked up OpenRouter, but it’s the ‘SaaS’ solution for the problem right now.

However, relying on OpenRouter effectively swaps one middleman for another. Instead of trusting the App Developer with my keys, I now have to trust OpenRouter. While they are reputable, it still centralizes my data and keys in one honey pot.

Also, my aim with this is too is that it gets adopted, which I think goes down to the people who use it to improve it and make it better for everyone, and I should mention that it is also compatible with openai’s sdk.

Nonetheless, really appreciate your insight and time, and good luck to you too.

1 Like