Protecting enterprise AI: How to manage API keys in Models-as-a-Service (MaaS)

Every team that moves an AI model from experimentation to production hits the same wall. The model works. The serving stack works. Then someone asks how the continuous integration (CI) pipeline is going to authenticate, and the room gets quiet.

What happens next is predictable. A developer's personal token gets copied into a secret. Or a service account gets created with more access than anyone intended, shared across pipelines, and forgotten. The traffic flows. Nobody knows whose budget it counts against. When that developer moves teams 6 months later, the credential lives on in places nobody knows about.

API keys in Models-as-a-Service (MaaS) exist to fix this. Not as another credential system, but as the way applications join the same governed access model that already works for people.

MaaS in Red Hat OpenShift AI

MaaS, recently released as a generally available (GA) capability in Red Hat OpenShift AI, is a strategic approach to delivering AI models as consumable, shared resources through centralized API endpoints, allowing users across an enterprise to access them on demand.

This system is powered by an embedded AI gateway, leveraging Cloud Native Computing Foundation (CNCF) projects and open source standards such as Envoy, Kuadrant, and Istio.

When you create an API key, it binds to an administrator-defined subscription, defining which models the team can use, how many tokens they can consume, and under whose name the usage is tracked. That binding happens at creation time, not later, and not optionally. It's what separates this from just another API key system.

The application never needs to know any of this. It has a bearer token. The platform takes care of the rest.

Say a team has analysts querying a Granite model interactively through the platform. When they want to add a nightly batch pipeline, they create a key, choose their subscription, and hand it to the pipeline configuration. The pipeline runs under the same rules as the analysts.

In practice, creating a key takes a few clicks in the OpenShift AI dashboard. You give it a name, choose the subscription it belongs to, and the key is returned once.

Create API key dialog in the OpenShift AI dashboard, showing name, description, subscription (with available models and token limits), and expiration fields.

The key is returned exactly  once. From that point, the pipeline uses it like any OpenAI-compatible endpoint:

Figure 1: Create API key dialog

The API keys list appears in the OpenShift AI dashboard, showing an active key with its subscription, owner, creation date, last used, and expiry date.

Figure 2: API keys dashboard

From that point, the pipeline uses it like any OpenAI-compatible endpoint:

curl "${MAAS_URL}/v1/chat/completions" \
  -H "Authorization: Bearer sk-oai-..." \
  -d '{"model": "granite-3-8b", "messages": [{"role": "user", "content": "Summarize this report"}]}'

That's it—the pipeline doesn't know about subscriptions, policies, or rate limits. It has a bearer token and a URL. The platform handles the rest.

Every developer on the team creates their own key. There's no shared credential to pass around, no ticket to file. Each key is tied to the subscription of the person who created it, so rate limits and usage are tracked against that individual's quota, not pooled across the team. Three developers, three separate keys, three separate quotas. The credential is personal, and the access model is consistent. The keys are individual, and governance is shared.

This works the same way whether the model runs on the cluster or is a vendor-hosted endpoint, like AWS Bedrock, Microsoft Azure OpenAI, or Anthropic, your organization has connected through MaaS. The pipeline doesn't care where the model lives. The key, the access rules, and the usage tracking are identical.

What the lifecycle actually looks like

Lifecycle of API key usage

Keys have a maximum lifetime set at the platform level. While active, every request the application makes lands in the same showback dashboards as human traffic from that subscription. There's no separate view for "machine use." It's all one picture, giving administrators granular visibility into token consumption to accurately attribute costs.

If a key expires, you create a new one. If something goes wrong before then, revocation is immediate and auditable. When a team leaves the platform, their keys go with them. There's nothing to hunt for, and nothing to untangle from shared configs.

At every point in this cycle, the platform knows who owns the traffic and what rules apply to it.

The audit conversation changes

If you've ever sat through a security review for an AI workload, you know the moment. Someone asks how application credentials are managed. The answer usually involves a lot of "well, we have this service account that..."—followed by caveats.

With API keys bound to subscriptions, the answer is short. Every application credential is scoped, time-limited, tied to a named subscription, and revocable. Use is fully visible in centralized showback dashboards. The same governed path that works for a data scientist at a terminal works for a pipeline running at 3 AM.

That was the goal. There is no separate credentialing system for machines—the same access model applies to both human and application access.

For a full walkthrough on creating and managing keys, see the token management guide.

To learn more about the Models-as-a-Service, read, “Scaling enterprise AI: Delivering Models-as-a-Service with Red Hat OpenShift AI 3.4.”