When Your Bug Meets Their API Key
When Your Bug Meets Their API Key: A BYOK Reality Check
Meta description: A real debugging story about putting a client's AI assistant live on their own API key. Why BYOK isn't just pricing—it's a trust boundary that changes everything.
You send your OpenRouter key. We build your AI assistant. The bug happens on our side. Who pays for the mistake?
If you answered "the vendor," you're thinking like most people. You're also wrong.
Here's what actually happened when we put a client's AI assistant live—and why bring-your-own-key (BYOK) changes the entire game.
The Setup: Their Key, Their Rules
The client wanted an AI assistant on their site. Standard request. They sent their OpenRouter key and pointed us to their dashboard URL. Our rule is simple: every LLM feature runs on the customer's key, never ours. Their key, their data, their box.
This isn't a pricing decision. It's a trust boundary.
When you control the API key, you control:
- What models run
- How much gets spent
- Who can revoke access
- Where the data flows
The vendor never holds the thing that can be abused.
The Process: Edge First, Credentials Second
We follow a specific order when setting up client integrations. Gate order matters:
- Tighten the edge first — The API allowed any origin initially. We locked it to same-origin only.
- Add the key second — Never touch credentials until the perimeter is secure.
- Verify no path echoes or logs it — Keys don't belong in logs, ever.
Edge guard first, credential second. This sequence prevents the most common ways API keys leak or get abused.
The Bug: Wrong Diagnosis, Right Process
First attempt failed. The assistant returned dashboard-only replies instead of live responses.
Our initial diagnosis blamed a Cloudflare bot challenge on the default HTTP user agent. We staged a relay to work around it. Classic debugging mistake: we assumed the obvious culprit without testing the actual path.
The real cause was simpler and more embarrassing. The configured base URL pointed to the client's dashboard, not the API endpoint. One line correction, container recreation, and a same-origin POST returned a live reply from a 7B open-weight model—with the unchanged default user agent.
The Learning: Record Wrong Turns
We recorded the wrong diagnosis as a correction unit rather than editing it away. Why keep the mistake visible?
Predict before you look. The relay would have shipped a fix for a problem that did not exist. Wrong diagnoses teach you about your assumptions. They show where your mental model breaks down.
Most vendors hide their debugging process. That's a mistake. Your engineering team learns more from failed hypotheses than successful ones.
The Economics: Zero Cost, Maximum Control
Cost to us for the client's assistant: zero.
Billing, model choice, and rate limits belong to them. They can revoke the key and the feature stops immediately. No vendor lock-in, no surprise charges, no "contact sales" to turn things off.
This flips the traditional SaaS model. Instead of the vendor controlling costs and the customer hoping for reasonable pricing, the customer controls costs and the vendor hopes for reasonable usage patterns.
Why BYOK Changes Everything
Most infrastructure vendors treat API keys as a convenience feature. Pay extra, bring your own key, get better rates. That misses the point entirely.
BYOK creates a different relationship:
Traditional model: Vendor holds keys, customer trusts vendor's security, billing, and access controls.
BYOK model: Customer holds keys, vendor proves they don't need to be trusted with the critical path.
The second model scales trust differently. You're not betting on the vendor's security practices. You're betting on their ability to build features without requiring dangerous permissions.
The Trust Boundary in Practice
When debugging fails in a traditional setup, the vendor has full access to retry, test different parameters, and potentially run up costs while figuring things out.
With BYOK, debugging requires coordination. We can't just "try a few things" on the client's dime. Every test request costs them money and uses their rate limits.
This constraint makes debugging better, not worse. It forces you to:
- Test thoroughly in development
- Diagnose before you touch production
- Document your assumptions clearly
- Get the fix right the first time
Implementation Details That Matter
The technical implementation reveals the trust model:
Same-origin enforcement prevents other sites from using the client's assistant (and their API budget).
No credential logging means API keys never appear in our logs, even during errors.
Container isolation ensures each client's configuration stays separate.
Immediate revocation means turning off the key kills the feature instantly.
These aren't just security best practices. They're proof that the vendor doesn't need persistent access to the customer's resources.
When Vendors Hold Keys vs. When Customers Do
Vendor-held keys optimize for convenience. Customer-held keys optimize for control.
If you're evaluating infrastructure that touches expensive APIs (LLMs, cloud services, third-party data), ask which model the vendor supports. The answer tells you whether they see themselves as a gateway or a tool.
Gateways accumulate power and risk. Tools distribute both.
The Bottom Line
The bug was ours. The cost was theirs. The control stayed where it belonged.
That's not a failure of the BYOK model—it's the model working exactly as designed. When something breaks, the customer decides how much to spend fixing it and when to stop trying.
Your API key, your rules, your budget. The vendor builds features without requiring trust in their financial judgment or security practices.
That's a better foundation for infrastructure that scales.