If someone compromised one of your project's dependencies today, would they be able to steal your OpenAI, Anthropic, or Gemini API keys?
The answer isn't based on which LLM provider you use or how secure your codebase is. It mostly depends on one architectural decision that many teams never think about: where your provider API key actually lives while your application is running.
If that key lives inside your application's own process, every dependency running in that process shares the same environment. A compromised package doesn't need to break into your infrastructure. It simply executes with the same privileges as your application and can access the same credentials your code can access.
If the provider key lives in a separate network proxy instead, the application never holds the provider credential at all. Even if a dependency is compromised, the attacker can only access whatever limited credentials exist inside the application process. That doesn't eliminate risk, but it can reduce the blast radius when something goes wrong.
In this article, we'll look at the two dominant LLM gateway architectures, examine exactly where API keys live in each design, walk through a reproducible demo that shows the difference in practice, and discuss why reducing blast radius often matters more than trying to eliminate every possible attack.
