The quiet sprawl of model API keys

Most organisations do not decide to adopt AI in a single meeting. It arrives one key at a time. An engineer signs up for a model provider to prototype a feature. A marketing lead pastes a key into a no-code tool. A finance analyst runs a spreadsheet plugin that quietly calls a model on every recalculation. None of this is reckless. It is how useful things spread. The problem is what the pattern leaves behind.

What a scattered key actually is

A model API key is not a convenience. It is a standing grant of authority to send your organisation's data to an external system and act on the response. When keys live in browser extensions, personal accounts, notebooks and shared documents, you lose the ability to answer basic questions:

• Which systems and people can currently call a model, and on whose behalf?
• What data has left the building through those calls?
• If a key is exposed, how quickly can you revoke it without breaking work no one has documented?

If the honest answer to any of these is "we would have to go and look," the authority has already outrun the control.

The failure mode is not dramatic

Key sprawl rarely produces a single catastrophic breach. It produces slow erosion. Spend appears on invoices that no one can attribute to a project. Sensitive records pass through a consumer tier with different retention terms than the ones your legal team approved. A departed contractor's key keeps working for months. Each item is minor. Together they describe an organisation that cannot say what its AI is doing.

Centralise the path, not the ownership

The response is not to ban tools or to route every request through one team as a bottleneck. It is to make model access pass through a controlled gateway rather than through individual keys:

• Identity and authority attach to every call, so a request is tied to a person or service and the permissions they actually hold.
• Policy decides what is allowed before the call is made, rather than being reconstructed afterwards from logs.
• Evidence records what was asked, what was sent, and what came back, in a form you can inspect later.

The individual keys move behind the gateway. People keep their tools. What changes is that authority becomes visible and revocable in one place.

Sovereignty is control, not a locked room

It is tempting to read this as a call to isolate everything on private infrastructure. That misreads the goal. Sovereignty here means retaining control over your data, your model access and your operational decisions, whichever providers you use. A gateway lets you switch providers, apply different policies to different data classes, and withdraw access cleanly, without asking every team to change how they work.

A practical starting point

You do not need a programme to begin. You need an inventory and a direction:

• Find every place a model is currently called, including personal accounts and embedded tools.
• Identify which of those calls touch data you would not want to leave uncontrolled.
• Route the highest-sensitivity paths through a governed gateway first, and expand from there.

The aim is not to slow AI down. It is to make sure that when someone asks what your AI can reach and on whose authority, the answer is something you can produce, rather than something you have to go and discover.