Bring Your Own API Key: AI Tools and Your Data

The AI question in procurement isn't "is it clever"

When an AI-touching tool reaches a security review, nobody in that room cares how clever the AI is. They care about four things: whose model is it, whose key pays for it, whose data goes into it, and what leaves the network.

Most vendors answer those with a paragraph of reassurance and no architecture — "we take security seriously," "your data is safe with us." A reviewer can't sign off on adjectives, so the questions get asked again, in writing, and the review that should take an afternoon takes a quarter.

The fix is to write the architecture down. This is that write-up for an AI test tool: the four questions in a reviewer's own words, what bring-your-own-key actually means, what self-hosting does and doesn't change, and the checklist to take to any vendor in this category — us included.

The four questions a reviewer asks

Strip the review down and it's four questions. A vendor who can answer them with architecture instead of adjectives passes quickly.

• Whose model is it, and who runs it? Is the intelligence your chosen provider's, or something the vendor operates and won't fully describe?
• Whose API key authorises the calls? Do the AI requests go out under your account and credentials, or the vendor's?
• What data leaves our network, and where does it go? When an AI feature runs, what content is sent, and to whom?
• Is our data used to train anything, and how long is it kept? Retention and training are the questions that end deals when the answer is vague.

None of these is about cleverness. They're about accountability and data flow, and they have concrete answers — if the tool was built with them in mind.

Bring your own key, concretely

"Bring your own API key" sounds like a billing detail. It's actually the cleanest answer to the first two questions, so it's worth spelling out.

It means you supply your own key for your own model provider. The AI calls go out under your account, authorised by your key, and billed to you. Three things follow. You choose the model, and you can switch it whenever you like. You see and control the spend directly, with no vendor markup in the middle. And the data in those calls is governed by your existing agreement with the provider — not by the tool vendor's terms.

Just as importantly, the vendor never holds the power of your key as if it were their own. With Tesbo, keys are yours on every plan: your key, your model, your bill, your provider relationship. That single design decision answers "whose model" and "whose key" before the reviewer finishes asking.

What self-hosting changes — and what it doesn't

Self-hosting the tool means the application and its database run on your own infrastructure. It's a real tightening of the boundary, and it's also commonly oversold, so here's the honest version.

What it changes: your test data at rest lives on your servers, under your control, and the tool itself sends nothing home — no usage telemetry leaving the building unless you turn it on. For questions three and four about the tool, that's a strong answer.

What it does not change: the moment you use an AI feature, the content of that request still goes to whatever model provider your key points at — unless that model is itself something you run locally. Self-hosting the app does not self-host the model. So self-hosting removes the tool vendor from your data path, but it does not remove the model provider from it, and it doesn't make the AI question disappear.

Training and retention, plainly

Training is really two questions wearing one coat, and they have different owners.

First: does the tool vendor train on your data? For Tesbo the answer is no — it doesn't train on your data and doesn't ship a model of its own. That's a boundary the vendor controls and can state flatly.

Second: does your model provider train on or retain your prompts? That's between you and the provider, and it depends on the plan and agreement you hold with them. Many offer API tiers with no training and short or zero retention, but that's theirs to guarantee, not the tool vendor's — so confirm it in your provider's own data-use terms. Two boundaries, two separate checks: the vendor's answer can be clean and you still verify the provider's yourself.

Agent access, same rules

One more piece a reviewer increasingly asks about: agent access. Tesbo exposes an MCP server, so an AI agent can work with the case tooling directly rather than through a person clicking around.

The important thing is that the rules don't loosen when an agent is driving. The agent still uses your keys, a person still approves what enters the trusted record, and nothing gets written into the suite unattended. Agent-accessible does not mean agent-autonomous — the human acceptance step is the same one that governs everything else. It's the same reviewed record, reached a different way.

What to ask any vendor — even us

Take this checklist to any AI test tool you evaluate, and hold us to it too:

• Do we bring our own model key, or is the model yours?
• Do you train on our data? Get the answer in writing.
• When an AI feature runs, what data leaves our network, and where does it go?
• Can we self-host, and exactly what does that change about the answers above?
• What's the data retention, and can we control it?
• Do you hold any security certifications?

On that last one, the honest answer for Tesbo is that it holds none today — and good architecture is not the same thing as certification. A vendor that answers all of these with specifics, rather than reassurance, is the one whose review won't quietly consume your quarter.