RBAC for AI: Governing the AI Control Plane

Accessing the AI control plane entails a nuanced distinction from determining which aspects of it a user can manipulate. Virtual keys serve as the runtime embodiment of governance decisions; a workload brings along policy alongside its identity, resulting in an order command that invariably triggers a budget_exceeded message. The significance of this assurance hinges on one query: who holds the authority to log into the control plane and adjust the cap?

The security of the enforcement configuration directly influences the reliability of enforcement. Once a gateway morphs into a control plane, its administrative interface becomes an integral component of the security perimeter, rendering Role-Based Access Control (RBAC) insufficient. So, the disparity between configuration, policy, and authority comes into play.

Configuration pertains to altering a team's display name; policy involves specifying which models a team can access; authority dictates who is authorized to define that policy. Traditional control planes amalgamate all three within a single dashboard, leading to the inadvertent delegation of authority when configuration was the intended outcome.

Bifrost's RBAC framework sidesteps this issue by treating permissions as combinations of resources and operations, encompassing virtual keys, model providers, guardrails, MCP gateways, tool groups, audit logs, adaptive routing, and user provisioning. This yields forty-two distinct permissions, distributed across three system roles: Admin, Developer, and Viewer.

The distinction between Developer and Admin transcends seniority; rather, it represents the spectrum of permissions that govern what others are permitted to accomplish. Traditional RBAC falters because an identity provider only discerns group membership, unaware of the specifics of virtual keys, guardrail configurations, or the ramifications of revealing redacted logs.

The crux of the issue remains valid: organizations frequently utilize Okta or Entra, relying on pre-existing group mappings and responsibilities, and there is no inclination to introduce an additional identity layer. Authentication can persist as is, while the control plane governs what an authenticated individual is permitted to administer, with Bifrost facilitating this transition by mapping IdP groups, app roles, and claims to roles across various identity providers, with assignments synchronized on each session.

Two points warrant attention before adopting this approach. Firstly, when provisioning is disabled, the permissions API returns full permissions for every resource, a suitable default for a single-operator setup but potentially perilous for larger organizations that rely on RBAC. Secondly, when a user possesses multiple roles, the role with the highest privileges takes precedence, a union rather than an intersection, which is the prevailing mechanism that inadvertently undermines the principle of least privilege.

Once a user is added to an additional IdP group during an organizational restructuring, they inherit the highest set of roles rather than the intersection of their roles. This highlights the need for AI RBAC to control aspects beyond the conventional CRUD operations. Reveal, for instance, grants permission to un-redact reversible redactions in logs, a data access privilege that should be treated separately from administrative decisions.

Inference operations bestow the ability to invoke chat completions, embeddings, images, audio, or moderation services. A control-plane role can extend data-plane access, signifying that the boundary between the two planes itself constitutes a permission. Other permissions must be evaluated based on their consequences rather than their structure.

Changing routing may appear as mere infrastructure until it redirects a workload to an unreviewed model. Adjusting the budget might seem purely financial until it determines whether a production workload continues running. Lastly, configuring an MCP tool group carries the most significant implications, as a model completion generates information while a tool invocation can trigger an action.

Permission granularity and resource scope are intertwined; without both, a permission grants unfettered access to any resource. Two engineering managers, both authorized to create virtual keys, inspect usage, and manage budgets, face a dilemma when one operates within the Search domain, while the other oversees Customer Support.

A permission labeled VirtualKeys: Update enables them to modify each other's credentials, but the scope of this authority remains unaddressed. This exemplifies the inadequacy of a permission matrix alone and underscores the necessity of row-level scoping, which operates in tandem with the permission matrix. A role's data access can be classified as own-data, team-data, or all-data, with each governed resource tracking the user who initiated it.

Consequently, the statement "I can manage virtual keys" and "I can manage these specific virtual keys" become separate propositions. Constructing roles based on responsibilities rather than job titles is paramount. Developers, managers, and directors represent individuals, not authority over infrastructure. Instead, organizations should inquire about who oversees provider configuration, who manages organizational spend, who can issue credentials, and who requires the ability to inspect usage without altering policy.

By addressing these inquiries, organizations can devise roles that align more closely with the org chart's expectations. Finally, an auditor can be categorized based on the resources they manage, ensuring a more precise allocation of responsibilities within the AI infrastructure.