AI Governance Guide: Access Profiles, RBAC, DAC

AI governance architecture is the set of access-control layers that decide which users and applications can reach which models, spend which budgets, and see which data across an organization's AI traffic. As teams move from a handful of shared provider keys to hundreds of engineers, agents, and business units calling large language models, three layers become load-bearing: access profiles, role-based access control (RBAC), and data access control (DAC). Bifrost, the open-source AI gateway built in Go by Maxim AI, implements all three as a single control plane, so enterprises can route, govern, and secure every model call from one place. This post explains how each layer works, how they combine, and how to reason about them when designing governance for production AI.

What Is AI Governance Architecture

AI governance architecture is a layered system of access controls that authenticates callers, restricts which providers and models they can use, enforces per-user budgets and rate limits, and scopes which data each identity can see. It sits between your applications and your LLM providers, turning ungoverned direct API calls into policy-enforced traffic.

In Bifrost, that architecture is built on a single primitive: the virtual key. Virtual keys are the primary governance entity. Each one carries its own access permissions, provider and model restrictions, budgets, and rate limits, and applications authenticate against a virtual key rather than a raw provider key. Everything else in the governance stack either decides who gets a virtual key, what that key is allowed to do, or which rows the holder can see.

The three layers map cleanly onto three questions:

• RBAC answers what operations can this user perform on governance resources like keys, providers, and logs.
• DAC answers which rows of data can this user see once an operation is allowed.
• Access profiles answer how do we provision the right virtual key, budget, and limits for every user without handing out keys by hand.

Why AI Governance Architecture Matters for AI Teams

Ungoverned AI usage is now a measurable source of enterprise risk. Gartner has projected that by 2030, more than 40% of enterprises will experience a security or compliance incident tied directly to shadow AI, and IBM's 2025 Cost of a Data Breach Report found that roughly one in five organizations has already had a breach linked to unsanctioned AI. Most of that exposure traces back to the same root cause: model access that no one can attribute, cap, or revoke.

A governance architecture addresses this at the infrastructure layer rather than through policy documents alone. The National Institute of Standards and Technology frames trustworthy AI around clear roles, accountability, and the ability to demonstrate control, all of which depend on knowing who is calling which model with which data. For platform and security teams, a centralized governance layer delivers concrete outcomes:

• Attribution: every request maps to a user, team, or customer rather than a shared key.
• Cost control: budgets and rate limits are enforced per identity, not estimated after the fact.
• Least privilege: users reach only the providers, models, and data their role requires, following the principle of least privilege.
• Auditability: immutable audit logs support SOC 2, GDPR, HIPAA, and ISO 27001 reviews.

These properties matter most for regulated industries and large teams, which is why Bifrost is built as the AI gateway for enterprise deployments, including VPC-isolated and on-prem environments.

Role-Based Access Control (RBAC): Governing What Users Can Do

Role-based access control governs which management operations a user can perform. RBAC in Bifrost defines roles as sets of permissions, where each permission is a combination of a resource and an operation, and users acquire permissions by holding a role rather than through individual grants. This is the same model standardized by NIST, where permitted actions are tied to roles instead of individual identities.

Bifrost ships with three system roles that cover common access patterns:

• Admin: full access across all resources and operations (42 permissions).
• Developer: create, read, update, and delete access to technical resources, with view access to logs and cluster (27 permissions).
• Viewer: read-only access to all resources (14 permissions).

System roles cannot be deleted, but their permission sets can be tuned, and teams can create custom roles for functions like QA, security, compliance, or a time-boxed auditor role for contractors. Each role is built from permissions across protected resources, including virtual keys, model providers, logs, observability, users, audit logs, guardrail configurations, plugins, the MCP gateway, and cluster settings. Every resource supports up to four operations: view, create, update, and delete.

RBAC also connects to identity. Through user provisioning, Bifrost integrates with identity providers over OAuth 2.0 and OIDC, plus inbound SCIM 2.0, so roles are assigned automatically from IdP groups and claims. A user signs in with corporate credentials and inherits the right role and permissions immediately, with no manual account creation.

Data Access Control (DAC): Governing What Data Users Can See

Data access control governs row-level visibility. Where RBAC decides what operations a user can perform, data access control scopes the result set of those operations to the rows the user is entitled to view. The two layers are complementary: RBAC gates the action, DAC filters the data the action returns.

It is worth naming a common point of confusion here. In classic security literature, "DAC" usually refers to discretionary access control. In Bifrost, DAC means data access control, a role-driven row-scoping mechanism. The distinction is deliberate: scope is configured on the role, not left to the discretion of individual resource owners.

Every role in Bifrost carries a data access scope with one of three values:

• Own data (own-data): members see only rows they personally created or own, such as virtual keys assigned to them, prompts they authored, and logs they produced.
• Team data (team-data): members see their own rows plus every row created by any user on any team they belong to.
• All data (all-data): no row filtering, which is the default for system roles such as Admin.

DAC is designed to fail closed and to roll out safely. Invalid scope values are rejected at the API, and a team-data user with no resolved team list sees an empty result set rather than falling back to all data. Rows created before DAC was adopted remain visible under every scope, so enabling it on an existing install does not silently hide data. Scoping applies to resources that carry an ownership concept, including virtual keys, prompts, teams, customers, routing rules, access profiles, guardrail configurations, business units, MCP clients, MCP tool groups, and API keys.

Critically, DAC is inference-aware. When a request arrives on the inference path with only a credential, Bifrost resolves the identity and applies the same scope logic used for dashboard sessions:

• A virtual key is resolved to its owner, and the owner's scope applies.
• An API key is resolved to the API key's owner, along with their role and team memberships.
• A user token (JWT) identifies the user directly through its claims.

The result is consistent behavior: a team-data user's credential, called server-to-server with no dashboard session attached, still cannot see another team's data.

Access Profiles: Provisioning Governance at Scale

Access profiles are how governance is provisioned to every user without manual key management. An access profile is a reusable policy template that describes what a user, team, or business unit is allowed to do. When a profile is assigned, directly or by attaching it to a role, Bifrost creates a per-user copy of the policy and automatically issues a virtual key that carries the policy's provider list, model whitelist, budgets, rate limits, and MCP tool access.

This closes the gap between defining a policy and enforcing it on real traffic. The key properties are:

• Reusable policy: define a profile once, for example an "Engineering" profile, and apply it to every user in a role.
• Per-user enforcement: each user gets an independent copy with isolated budget and rate-limit counters, so usage accrues separately per person.
• Role-default auto-assignment: mark a profile as a role's default, and users who gain that role are provisioned automatically.
• Safe propagation: edit the template, then push selected fields (budgets only, MCP only, and so on) to every user copy in one operation.
• Managed virtual keys: auto-issued keys are write-protected, so a user cannot weaken their own policy by editing the key directly.
• Audit and versioning: every change to a profile is recorded with a full snapshot history.

Because access profiles auto-allocate virtual keys, users never need to be handed raw keys and operators never write keys by hand. That is what makes the model workable at the scale of hundreds or thousands of users, and it is a core part of the enterprise governance surface in Bifrost.

How the Layers Work Together in Bifrost

The three layers combine into a single enforcement path with virtual keys at the center. RBAC decides which management operations an identity can perform. DAC scopes which rows that identity sees. Access profiles generate the virtual key that carries each user's runtime policy, and user provisioning ties all of it back to your identity provider. The result is a governance architecture where a request is authenticated, authorized, scoped, and metered before it reaches a provider.

How is RBAC different from data access control?

RBAC controls which operations a user can perform on a resource, such as creating or deleting a virtual key. Data access control decides which rows of that resource the user can see once the operation is permitted. RBAC gates the verb; DAC filters the nouns.

Do access profiles replace virtual keys?

No. Access profiles are templates that generate and manage virtual keys. The virtual key remains the enforcement primitive that carries provider access, budgets, and rate limits at request time; the access profile is the reusable policy that provisions and updates those keys at scale.

Where does user provisioning fit in?

User provisioning connects Bifrost to your identity provider over OIDC and SCIM 2.0, so role assignment, team membership, and business unit mapping flow automatically from your IdP. RBAC and DAC then act on those roles, and access profiles provision the matching virtual keys.

For teams designing this end to end, the Bifrost governance documentation and enterprise governance resources walk through each layer in depth, alongside budget, rate-limit, and audit-log configuration.

Getting Started with Bifrost

A durable AI governance architecture is not a single feature but a stack: RBAC for operations, data access control for row-level visibility, and access profiles to provision the virtual keys that enforce policy on live traffic. Bifrost brings all three together in one open-source AI gateway, with identity-provider integration, immutable audit logs, and enterprise deployment options for regulated environments. To see how Bifrost can centralize governance across your models, providers, and teams, book a demo with the Bifrost team.