Keys and models

A model API key is a bearer credential tied to a billing account. Provider keys may have no expiry, so distribution and rotation need explicit controls.

Central key distribution

A team that needs model access may open a provider account with a corporate card and put the key in a shared document. Copies then reach other teams, repositories, and CI systems. Once the original owner changes roles, rotation becomes difficult because no one has a complete dependency list.

Missing key distribution predictably creates unmanaged copies. Training may reduce some copies, but it cannot provide inventory, expiry, or revocation.

Manage provider keys through a service that issues scoped credentials and supports expiry:

• Applications and tools authenticate to an internal gateway with their own identity. The gateway holds the provider credential.
• The gateway records the application, team, and user for every call. That record supports cost and traces.
• Keep provider-key rotation inside the gateway so consumers do not need a coordinated change window.
• Revoke one consumer without interrupting other users of the provider key.

Model access options

Vendor SaaS endpoints are quick to adopt and place more control with the provider. They fit many internal workloads, while policy may exclude them for sensitive data.

With BYOK, a product uses credentials from your provider account under your billing and data-processing terms. Where the product vendor does not receive the underlying data, this can keep processing inside the regulated organization's provider account.

Models served through your cloud account run under its contract, network boundary, and audit regime. This route may avoid a separate provider relationship.

Local or self-hosted models support environments where data cannot leave a defined boundary. They also reduce dependence on a provider's model-retirement schedule.

Protected health information requires an endpoint covered by a Business Associate Agreement. Coverage is a contractual fact that the routing layer needs in its policy data.

Supporting several routes calls for centralized Control policy. Applications should receive an approved endpoint without implementing the decision themselves.

Usage attribution

Metering records who consumed model capacity and how much they used. Billing determines who pays. Usage records are useful before internal chargeback begins.

Without attribution, an unexpected invoice can trigger a broad spend cap. Per-consumer records let teams find the batch job or application responsible and respond at that scope.

At the gateway, record the model, input and output tokens, latency, application, team, and user for every call. Cost depends on this record.

Consequences of a misplaced key

A leaked key permits unauthorized spend and authenticated access to the provider account. Depending on the provider, that account may also contain fine-tuned models, uploaded files, assistant configurations, and request logs.