An enterprise AI governance stack is not a gateway feature. It is a sequence of decisions that has to hold from organizational intent to runtime action.
Five posts into The AI Control Plane, the individual controls are no longer the interesting part. Governance decisions, virtual keys, RBAC, access profiles, user lifecycle management, and MCP tool policy each solve a real problem. None of them is an enterprise AI governance stack by itself.
The harder question is how they fit together, and in what order.
Installing a gateway before deciding who may use which models gives you infrastructure without policy. Creating virtual keys before defining ownership gives you credentials without governance. Automating provisioning before cleaning up exceptions makes access sprawl faster. Giving agents tools before deciding which actions they may take converts model access into operational authority.
It is tempting to deploy the gateway first, because infrastructure is concrete: point applications at a new base URL, centralize credentials, turn on observability, call phase one complete. Those are useful changes and they are not yet governance. Without an explicit decision layer, a gateway centralizes whatever assumptions were already scattered across applications, and centralized ambiguity is still ambiguity.
A control plane does not create governance. It makes governance executable.
What Belongs in an Enterprise AI Governance Stack?
A working stack answers a set of related questions in deliberate order. Governance decisions, virtual keys, RBAC, access profiles, user lifecycle management, MCP tool policy, and the evidence those controls leave behind each solve a real problem.
| Layer | Question | Control |
|---|---|---|
| Governance | Who gets to decide? | Organizational policy and ownership |
| Identity | Who is this? | Enterprise identity provider |
| Authority | What may this administrator change? | RBAC and scoped permissions |
| Runtime policy | What may this workload use? | Access profiles and virtual keys |
| Lifecycle | How does authority change over time? | Provisioning and reconciliation |
| Capability | What may this workload actually do? | MCP tool filtering and execution policy |
| Evidence | What happened under that authority? | Logs, audit records, and retained state |
The important part is not the names in the right-hand column. Implementations change. The questions do not.
This is also why starting from a product checklist produces weak governance. "Do we have RBAC?" is less useful than "who is allowed to change a production model allow list?" "Do we support MCP?" matters less than "which workloads may invoke a destructive tool with no human present?" Design the stack around decisions, then map those decisions to mechanisms capable of enforcing them. The NIST AI Risk Management Framework is organized the same way, around functions like govern, map, measure, and manage rather than around any particular control implementation.
How Is Role-Based Access Control Different from Identity in AI Governance?
Once policy exists, the next temptation is to treat authentication as authorization.
An identity provider can establish that Alice works in Engineering and belongs to the Platform group. It does not know whether Alice should be able to change provider credentials, reveal redacted logs, edit access profiles, or grant an agent permission to invoke a tool. The administrative surface needs its own authorization model, with scope determining not just what an administrator may change but where.
Identity answers who. RBAC answers who may decide. Runtime policy answers what the workload may do.
Collapsing those layers creates shortcuts that look convenient during rollout and are painful to unwind. A broad administrator role becomes the place every exception lands, direct assignments accumulate because they solve today's problem faster than changing a role does, and eventually nobody can explain whether access exists because of policy or because someone needed it during an incident eighteen months ago.
When Should an AI Gateway Enforce Governance Policy?
A control plane can be introduced gradually. Governance cannot stay optional forever.
Earlier in this series there was an uncomfortable default worth returning to: allowing requests without governed credentials makes migration easier and also creates a bypass. That is reasonable while applications are moving behind the gateway. It is dangerous once leadership believes the migration is finished.
So the transition needs an explicit enforcement point, and the sequence into it is the part teams get wrong.
Inventory the workloads. Give them owners. Attach budgets, provider and model policy, expiry where appropriate, and tool permissions. Move traffic onto governed credentials. Find the systems that break. Fix those exceptions rather than exempting them permanently. Then require governed identity at inference.
Turning mandatory enforcement on before inventory and ownership creates an outage. Leaving it optional after migration leaves a control that exists on paper and constrains nothing. The control is present in both cases; only one sequence produces governance.
The same principle applies to budgets and tool access. Start with observation where you must, but decide in advance when observation becomes enforcement. A policy that stays permanently advisory is telemetry, not control.
How Does Identity Lifecycle Management Apply to AI Access?
Governance is never finished, because organizations do not stay configured. People join, teams reorganize, acquisitions create new reporting lines, projects end, employees leave, and service accounts outlive the people who created them.
The lifecycle has to reach runtime objects, not just identities. Deactivating an SSO account accomplishes little if runtime credentials or upstream provider tokens remain independently usable. Deleting every object belonging to a leaver accomplishes something worse, because it destroys the record needed six months later to explain what that person could do.
Authority has to expire without history disappearing.
And some actors never enter this lifecycle at all. Pipelines, shared service accounts, and manually issued credentials need explicit owners and review periods, because no HR event will ever deprovision them.
How Do You Govern MCP Tools and AI Agents?
Tool governance belongs late in the sequence, not because it matters least but because it depends on nearly everything above it. Before granting a workload access to a tool, the organization should already know who owns that workload, which policy applies, who may change that policy, how the credential is governed, and what happens when ownership changes.
Only then is "may this agent invoke issue_refund?" a meaningful question.
Grant tool policy by consequence rather than convenience. Reading documentation, modifying a customer record, moving money, and deleting an account are not equivalent just because they arrive through the same protocol. And permissions compose: a database reader and an email sender may each be acceptable alone while together enabling a workflow nobody approved. Per-tool controls do not solve that. Governance has to review effective capability, not individual grants.
In What Order Should You Build an Enterprise AI Governance Stack?
Put together, the sequence looks less like a product rollout and more like dependency management.
- Define governance. Ownership, approved providers and models, budgets, exception authority, escalation paths.
- Connect identity. Use the existing enterprise identity system rather than building a second silo.
- Constrain administrators. RBAC and resource scope on the people who can change AI policy.
- Encode runtime policy. Model access, budgets, rate limits, and expiry represented in governed credentials and profiles.
- Inventory and migrate workloads. Every credential gets an owner; inference moves behind the control plane.
- Make enforcement mandatory. Close the ungoverned path once migration is done.
- Automate lifecycle. Reconcile joiners, movers, leavers, direct exceptions, and non-human identities.
- Govern capabilities. Add tools by consequence, and review what combinations of grants make possible.
- Preserve evidence. Retain enough state to explain who held authority, what policy applied, and what happened under it.
Rollouts vary. A company already deep into agentic systems may need to inventory tool access before it can cleanly redesign identity. Another may have mature IAM and no centralized AI policy at all. This is not a migration script.
It is a dependency graph. Skipping ahead will not necessarily make a later control fail technically. It makes the guarantee underneath it weaker.
Why Access Control Isn't Enough: AI Guardrails and the OWASP LLM Top 10
One honest limit, and it is a large one.
Everything in these six posts governs access and authority. Who decided, who may change the decision, what the workload may reach, what it may do, and what record survives. None of it governs whether the output is any good.
A perfectly governed request, from an approved workload, to an approved model, inside budget, invoking a permitted tool, can still return something wrong, biased, leaky, or harmful. No amount of RBAC catches that. Access control asks whether the request was allowed. It never asks whether the answer was correct.
That is a different discipline with different mechanisms: content guardrails, evaluations, red-teaming, output monitoring, and human review on consequential paths. Some of them can run in the same place. Bifrost applies guardrails to inference inputs and outputs and to MCP tool calls, so the enforcement point can be shared even where the disciplines are not. The OWASP GenAI LLM Top 10 is a reasonable map of what that second discipline has to cover, and very little of it is an access control problem. An organization that builds one while ignoring the other has solved one class of problem and left another largely untouched.
Which raises the question this series has circled without answering. The ninth step says preserve evidence. But six months after an incident, what does that evidence actually prove, who is allowed to read it, and would it survive someone with an interest in its being different?
The AI Control Plane Is Where Decisions Become Behavior
Across this series, Bifrost has been the concrete implementation of an enterprise AI governance stack because it puts many of these controls in one place: routing, virtual keys, budgets and limits, RBAC, access profiles, user provisioning, guardrails, and MCP governance. It is open source, while some of the enterprise identity and administrative capabilities discussed here sit in its Enterprise offering, and the documentation is the right place to verify that boundary.
The architectural argument is larger than any one implementation. Enterprise AI governance is not a collection of toggles bolted around a model API. It is a chain of authority running from an organizational decision to a runtime action, where every link answers a different question and every downstream guarantee assumes the upstream answers were legitimate.
A budget limit means little if anyone can raise it. A virtual key means little if ungoverned traffic routes around it. RBAC means little if direct exceptions never expire. Offboarding means little if autonomous credentials outlive the person who owned them. Tool filtering means little if nobody asks what the permitted tools can accomplish together.
The point of a control plane is not to make those problems disappear. It is to give an organization one place where its decisions become observable, enforceable behavior.
That is the enterprise AI governance stack.
Teams that want to see these controls running end to end can book a Bifrost demo.
This article was commissioned by the Bifrost team. The link to the Sovereign Systems Specification points to my own work. The architectural perspective and conclusions expressed here are my own.