Models-as-a-Service (MaaS) governance: Managing AI access and token quotas

In our previous post, we talked about the API key lifecycle in MaaS. In this article, we'll set up the governance layer those keys bind to, focusing on 2 core controls: managing token quotas (via MaaSSubscription) and defining model access rules (via MaaSAuthPolicy).

Models-as-a-Service (MaaS), an integrated component of Red Hat Openshift AI, aims to give enterprises a flexible GitOps friendly way to set up their policy framework.

Both attach to models through a MaaSModelRef:

• MaaSSubscription defines how much a user can consume in a given time window.
• MaaSAuthPolicy defines which models a user is permitted to call.

Subscriptions: Quota-backed entitlements

A MaaSSubscription defines the quota. It declares an owner (groups or users) and defines how many tokens they can consume within a time window. When an application creates an API key, that key binds to a subscription. The bound subscription travels with every request the key makes. The platform enforces the limits continuously; administrators do not watch and adjust them by hand.

A subscription can define a quota for a single model, or all the models across your enterprise. This gives enterprises flexibility in how they want to define the subscription and entitlement approach that maps people and workloads to specific models, instead of forcing a single "one size fits all" subscription shape. 

AuthPolicies: Access rules

A MaaSAuthPolicy defines access by naming a set of subjects (groups or users) and declaring which models they are permitted to reach. The separation from the subscription is intentional. A team can hold a premium subscription spanning many models while an auth policy limits them to a specific subset. They consume at premium rates; they see only what they are authorized to see. Because these configurations are independent, you can modify an auth policy to add a model without touching the subscription, or change the subscription's rate limits without affecting the policy. Each evolves on its own schedule.

The 2-gate system

Every request to a model passes through the MaaS API Gateway, where MaaSAuthPolicy (access) and MaaSSubscription (quota) are enforced in parallel per model. Both must pass before the request reaches the inference server.

Two gate conceptual diagram of the MaaS API Gateway component workflow

Fitting MaaS to your organization

Let's consider a real-life example. Your organization wants to create a "premium subscription" covering a broad set of models with a large token allowance.

Your data science team is one of the owners for that MaaSSubscription giving them quota to this series of models. However, a MaaSAuthPolicy grants that team access to only a subset of those models. This means they have premium quota but limited access to the models based on what the policy allows.

A second team, ml-engineering, shares ownership of the same premium subscription while holding a different auth policy that exposes a different subset of models. Identical quota treatment. Independent access scope. All of this is achieved without having to create unique subscriptions for every single group in your organization.

If a new team joins, an operator simply creates or modifies a subscription and a policy. That team will get access at the right rate and to the right models, all without having to touch a model server, gateway configuration, or per-endpoint role-based access control (RBAC).

How organizations map their structure to policy

The same custom resources (CRs) map to patterns most organizations already use:

• Environment tiers — Different subscription tiers for development, staging, and production workloads, without separate clusters or model deployments.
• Time-bounded programs — Pilots and partner integrations get their own subscription and auth policy, both delete cleanly when the program ends.

Built-in usage tracking on each resource attributes consumption to teams and workloads, something we'll explore further in a future article.

That's the shift— it isn't about a better ticketing system or more careful kubeconfig management, it's a governance model the platform enforces, that scales with the organization, and that leaves a legible, auditable record of every access decision, because the operational story is shared, not custom per project.

Going deeper

This post covers how MaaSSubscription and MaaSAuthPolicy work as access primitives, how the MaaS gateway enforces both, and how they compose to reflect real organizational structure. For the full reference on authoring subscriptions, scoping policies, and configuring rate limits per model, see the admin and architecture documentation.

Want to learn more or see MaaS in action?

• Watch the demo: Check out our video, Accelerate enterprise software development with NVIDIA and MaaS, or implement the corresponding AI quickstart on your own cluster
• Get the full picture: Read our A guide to Models-as-a-Service.
• Try it yourself: Reach out to your Red Hat account team to start a 60-day trial of Red Hat OpenShift AI.