Managing AI Access and Token Quotas with MaaS Governance

In this blog, we will learn how to manage AI Access and Token Quotas with MaaS Governance.

(MaaS), available as part of, provides organizations with a flexible approach to managing AI model access and usage policies.

MaaS uses a MaaSModelRef to associate governance rules with models. Two key resources work together to control how models are consumed:

• MaaSSubscription establishes the amount of model usage a user or group is entitled to within a defined period.
• MaaSAuthPolicy determines which models a particular user or group is authorized to access.

MaaS Subscriptions: Defining Usage Quotas

A MaaSSubscription establishes the usage entitlement assigned to users or groups. It identifies the subscription owners and specifies the number of tokens they are allowed to consume during a particular time period.

When an application generates an API key, the key is associated with a subscription. Every request made using that key carries the subscription context, allowing the platform to automatically track and enforce the applicable quota. This removes the need for administrators to manually monitor usage and adjust limits as consumption changes.

Organizations can design subscriptions around their specific requirements. A subscription may apply to an individual model or provide quota coverage across multiple models within the organization. This flexibility allows enterprises to create entitlement structures that correspond to different teams, applications, and workloads rather than relying on a universal subscription model.

MaaSAuthPolicies: Controlling Model Access

A MaaSAuthPolicy handles the authorization side of governance. It identifies the users or groups covered by the policy and specifies the models they are allowed to access.

Keeping authorization separate from subscription management provides greater flexibility. For example, a team could be assigned a premium subscription with access to a broad collection of models, while its authorization policy restricts that team to only the models it actually needs.

This separation also makes policy changes easier to manage. Administrators can expand or reduce model access without changing the team’s subscription. Similarly, token limits or subscription rates can be adjusted without modifying the authorization rules. Access control and consumption management can therefore evolve independently.

Two Layers of Protection

Requests to AI models pass through the MaaS API Gateway, where authorization and quota controls are evaluated before the request is forwarded to the inference service.

The process can be viewed as two separate gates:

1. MaaSAuthPolicy — Access control: Determines whether the requesting user or group is authorized to use the target model.
2. MaaSSubscription — Usage control: Determines whether the request falls within the user’s available quota.

The request proceeds to the inference server only when it satisfies the required access and usage conditions.

Two-gate conceptual diagram of the MaaS API Gateway component workflow

Conceptual representation of the two-gate MaaS API Gateway workflow.

Applying MaaS Governance Across Teams

Consider an organization that wants to offer a premium subscription with a substantial token allowance across a broad collection of AI models.

The data science team could be assigned ownership of this MaaSSubscription, giving the team access to the subscription’s available quota. However, its MaaSAuthPolicy could restrict the team to only the models relevant to its work.

This creates an important distinction: the team receives the same premium-level quota entitlement while its actual model access remains governed by its authorization policy.

Another team, such as ml-engineering, could use the same premium subscription while having a different MaaSAuthPolicy. Its policy could expose a separate set of models that align with its responsibilities.

This approach provides shared quota management with independently controlled access. Organizations do not need to create a separate subscription for every individual team simply because their model access requirements differ.

When another team or project needs to be onboarded, administrators can create or update the appropriate subscription and authorization policy. There is no need to modify individual model servers, repeatedly reconfigure the gateway, or implement separate endpoint-level RBAC rules for each team.

Translating Organizational Structures into Policies

MaaS custom resources can also be aligned with common enterprise operating models. For example:

• Environment-based tiers: Organizations can create different subscription levels for development, testing, staging, and production workloads while continuing to use the same underlying cluster and model infrastructure.
• Temporary initiatives: Pilot projects, partner integrations, and other time-limited programs can be assigned dedicated subscriptions and authorization policies. When the initiative concludes, the associated resources can be removed without leaving behind unnecessary access configurations.

MaaS also provides usage tracking capabilities that help organizations associate model consumption with teams and workloads. This creates a foundation for understanding how AI resources are being used and managed across the organization.

The broader benefit is more than simply replacing manual access requests or improving credential management. MaaS introduces a governance framework that can be enforced consistently by the platform. As organizations scale their AI adoption, access decisions and usage entitlements can remain structured, traceable, and auditable rather than becoming a collection of project-specific configurations.

Going Further with MaaS

MaaS Subscription and MaaSAuthPolicy provide complementary mechanisms for governing AI model consumption. Subscriptions manage usage entitlements and token quotas, while authorization policies determine which models users and groups can access. The MaaS API Gateway brings these controls together and applies them to model requests.

For detailed guidance on creating subscriptions, defining authorization scopes, and configuring model-specific rate limits, refer to the Red Hat OpenShift AI administration and architecture documentation