Running the AI on your own model provider key

What your own key changes

Bring your own key means the model call is made with a credential you issued, on an account you hold, under terms you signed. The software is the client. The relationship with the model provider stays yours.

• The contract. Retention, training use and regional processing are settled in your own agreement with the provider. Those are the terms your legal team has already read for every other use of that account.
• The bill. Usage lands on your invoice, listed by your provider. You can cap it or stop it from your own console at any hour of any day.
• The reach. A key you can revoke is a control you hold. Withdrawing it takes effect on the next call, not at the next contract review.

The other arrangement is workable and common: a vendor calls a model for you, with a key you never see. It moves three of the questions your auditor will ask onto a party you can see less of. The answer to each one then becomes a support ticket.

Where the key lives

A key is only as good as the handling around it. Two arrangements are supported, and both keep the secret on the server.

Typed for a session

Supplied on the connect card and held for that session only, server-side. It is never written into the page, never published to the browser, and never written to a log.

Locked in by an administrator

Held once per provider and scoped to a single Tableau site. It is encrypted at rest under its own salt, and written atomically with owner-only file permissions.

What the console shows

The provider, the site, and a hint of the last few characters. The secret is never echoed back to a browser. An administrator unsure which key is loaded rotates it instead of reading it.

What removal does

The key is resolved again on each page load. Deleting it removes the feature at once, not at the next sign-in.

Every save, rotation, enable, disable and removal is written to both the admin audit log and the change ledger. Who put a key on this site, and when, is a question with a recorded answer. Memory does not have to carry it.

Any OpenAI-compatible endpoint works

The address of the model service is a parameter, not a constant. Any endpoint speaking the OpenAI API can serve the call. One integration then covers several genuinely different deployments.

• A hosted provider account, called directly with your key.
• A managed deployment on a cloud platform you already use, addressed by its own resource endpoint and deployment name.
• A gateway your platform team already runs. That is often where prompt logging, rate limits and cost allocation were solved once, for every other team.
• A model running locally, on hardware inside your own network. That suits a site with no outbound route to a model provider at all.

The last one settles some procurements. A company that has ruled out sending content to a hosted model still has a route to the same features. The client speaks to a local model through the same interface it uses for a hosted one. The question moves from whether to use the feature to where to point it.

Complete with the AI off

The governance work is done by deterministic engines. Scanning, comparing, extracting, mapping and reporting all run with no model involved. They run the same way tomorrow as they ran today, which is what makes their output usable as evidence.

Leave the key out and the assistant is absent. The page is byte for byte what it was before.

That is a design commitment rather than a packaging trick. Where a model is offered, the calling code is wrapped. A missing key, a network failure or a rate limit returns the deterministic text instead. The flow around it carries on, and the feature steps down quietly to the engine underneath. You can enable it on a Tuesday and withdraw it on a Wednesday.

It also means an evaluation can start before any commercial talks with a model provider. Install it, connect it to a site, and exercise it on its own engines. The key becomes a decision you take later, with evidence already in hand.

Who holds what

The key

Yours. Issued from your provider account, supplied per session or locked to one site by an administrator.

The account

Yours. The model provider knows your company as its customer. Its usage console is the one you already log in to.

The terms

Yours. Retention and training use follow the agreement you signed, not one signed on your behalf.

The record

Yours, on your own server. Who called, when, which model answered, how many tokens it took, and an estimated cost.

The switch

Yours. A strict on and off per provider key. Withdraw the key and the feature goes with it.

Five rows, five owners, one name in every one of them. That is what this arrangement is for.

Questions worth settling first

1. Which account issues the key, and who can rotate it at short notice.
2. Which endpoint the calls travel to, and whether it sits inside a boundary your data classification already covers.
3. What your provider’s terms say about retention, and about training on the content of a prompt.
4. What the product records about each call, and whether that record holds content or usage.
5. What the features do once the key is withdrawn, and whether anybody has tested it.

The fifth is the one that gets skipped. It is also the one that matters on the morning you need to pull a key in a hurry. Ten minutes on a Thursday answers it. At speed, on the day, it is unanswerable.