Top 10 AI Governance Principles for Engineering Teams

TL;DR

• AI governance principles reduce risk only when each one maps to a control that runs on every AI request, not to a policy document.
• The ten principles in this guide are grounded in the NIST AI RMF, ISO/IEC 42001, the OECD AI Principles, and the EU AI Act.
• Identity comes first: budgets, model access, tool permissions, and audit evidence all depend on knowing who sent each request.
• An AI gateway such as Bifrost enforces most of these principles in one place through virtual keys, budgets, guardrails, MCP tool filtering, and audit logs.
• AI Gateway + Bifrost Edge, currently in alpha, extends the same policies to desktop apps, browser AI, and coding agents on employee machines.

AI governance principles are the commitments an organization makes about who can use AI systems, what those systems may do, what they may cost, and how their use is recorded. For engineering teams, the hard part is turning AI governance principles into controls that apply to every model call and agent tool call, across every team and provider. Bifrost, the open-source AI gateway built by Maxim AI, is the best choice for enterprises running mission-critical AI workloads that require best-in-class performance, scalability, and reliability, and this guide uses it as the enforcement layer for each principle.

What Is AI Governance?

AI governance is the set of policies, roles, and technical controls that determine how an organization builds, accesses, and monitors AI systems. In engineering terms, it answers four questions for every request to a model or agent tool: who is calling, what may they reach, what may it cost, and where is the evidence recorded.

Policy documents answer those questions on paper; production systems need them answered at runtime. The AI gateway between applications and model providers is the natural enforcement point because it sees every request first. For a longer treatment, see how AI governance works in practice.

The Bifrost AI gateway follows this model. Governance enforced at the AI gateway covers model access, budgets, and MCP tool permissions from a single policy layer, in front of 25+ providers and 10,000+ models behind one OpenAI-compatible API.

The AI Governance Frameworks Behind These Principles

Four public frameworks shape most enterprise AI governance programs: the NIST AI Risk Management Framework, ISO/IEC 42001, the OECD AI Principles, and the EU AI Act. They differ in legal force and scope, but they converge on the same engineering requirements: accountability, transparency, security, event logging, and human oversight of consequential decisions.

The NIST AI Risk Management Framework is intended for voluntary use, and NIST added a Generative AI Profile (NIST AI 600-1) in July 2024. ISO/IEC 42001 describes how to establish, implement, maintain, and continually improve an AI management system, and is the first standard of its kind.

The OECD AI Principles name five values-based principles, three of which translate directly into controls: transparency and explainability; robustness, security and safety; and accountability. The EU AI Act requires high-risk AI systems to record events automatically over their lifetime (Article 12) and to be designed so that people can override them or halt them in a safe state (Article 14).

Figure 1: Frameworks say what good governance looks like; the principles translate them into controls an AI gateway can enforce on each request.

The frameworks do not prescribe tooling. Teams that need a control-by-control crosswalk can use this guide to mapping AI governance controls to security frameworks.

AI Governance Principles at a Glance

The ten AI governance principles below cover identity, model access, operator permissions, spend, agent tools, human oversight, data protection, traceability, deployment boundaries, and unmanaged AI usage. Each row names the framework requirement it serves and the Bifrost control that enforces it, so the table doubles as a review checklist.

Teams can cross-check this list against these AI governance best practices for enterprise teams.

Identity and Access Principles

The first three principles establish who is acting and what they may touch. Without an accountable identity on each request, budgets cannot be scoped, guardrail violations cannot be attributed to an owner, and audit logs record activity that nobody owns. These principles implement OECD accountability and the NIST AI RMF Govern function.

1. Attribute every AI request to an accountable identity

Shared provider API keys make AI traffic anonymous: the provider bill shows a total, not the team, service, or person behind it. An accountable identity on every request is the precondition for every other principle here.

In the open-source Bifrost gateway, virtual keys are the primary governance entity. Each application, team, or user gets its own sk-bf-* key, which Bifrost accepts in OpenAI-, Anthropic-, Gemini-, and Azure-style headers, so existing SDKs authenticate without code changes. Keys can carry an expiry, after which requests fail with a 403.

On Bifrost Enterprise, user provisioning connects the identity provider through OIDC single sign-on and inbound SCIM 2.0, with setup guides for Okta, Microsoft Entra, Keycloak, Zitadel, and Google Workspace. With SSO configured, a request can carry an IdP token instead of a virtual key, and Bifrost applies that user's budgets and rate limits.

2. Grant least-privilege access to models and providers

Not every team needs every frontier model, and not every workload should reach every provider. Least privilege for models limits cost exposure and keeps regulated data on approved providers.

Bifrost enforces this with provider and model restrictions on each virtual key, and both default to deny. A key with no provider configurations blocks all providers, an empty allowed_models list blocks every model for that provider, and an explicit list permits only the named models.

At larger scale, access profiles define the allowed providers, models, budgets, rate limits, and MCP tools once and apply them to a role, team, business unit, or customer. A virtual key whose owner holds a profile is write-protected, so a user cannot weaken their own policy by editing the key, and every profile change is recorded with a snapshot history.

Figure 2: Each principle maps to a check with a defined failure response, so a policy violation stops the request instead of being found in a report later.

3. Separate the people who set policy from the people who use AI

The engineer calling a model should not be the person who raises their own budget or edits the guardrail that blocks their prompts. Separation of duties is a standard expectation in security audits, and an ISO/IEC 42001 management system assumes defined roles and responsibilities.

Bifrost Enterprise enforces this with role-based access control: three system roles (Admin, Developer, Viewer), custom roles such as "Auditor," and per-resource permissions covering virtual keys, logs, and audit logs. Roles can be assigned from IdP groups.

Data access control then decides which records each role sees: own data, team data, business unit data, customer data, or everything. A team lead with permission to view logs sees only their team's requests.

Spend, Tool, and Oversight Principles

Principles four through six govern what AI may consume and do. Cost limits stop runaway spend from loops and misconfigured agents, tool permissions bound what an agent can change in connected systems, and human oversight keeps a person accountable for consequential actions, as Article 14 of the EU AI Act requires for high-risk systems.

4. Treat AI spend as a governed resource

Agents can multiply token usage without anyone noticing until the invoice arrives. Spend needs an owner, a limit, and a reset period, like cloud compute quotas.

Bifrost, the AI gateway, applies hierarchical budgets at the customer, team, virtual key, and provider configuration levels. Every applicable budget is checked independently and any single failure blocks the request. Budgets reset on periods from one minute to one year, optionally aligned to calendar boundaries in UTC.

Token and request rate limits sit alongside budgets, and providers that exceed their own limits are excluded from routing. A spent budget returns a 402 and an exhausted rate limit returns a 429, so client code can handle each case explicitly.

5. Apply least privilege to agent tools

Models produce text; agents take actions. When an agent reaches MCP servers that query databases, send messages, or modify files, tool permissions become the most consequential access decision in the system.

Bifrost applies MCP tool filtering per virtual key with a deny-by-default rule: a key with no MCP configuration can use no tools, except from clients an administrator has explicitly marked "Allow by Default." Administrators allow specific tools per MCP client, and a caller-supplied tool header can only narrow the allow-list, never widen it. The allow-list is enforced again at execution time.

Virtual MCPs, previously called MCP Tool Groups, bundle a curated set of tools from one or more MCP servers behind a single /mcp/<slug> endpoint that is reachable only through the virtual keys it is attached to. For deeper patterns, see this guide to MCP tool filtering and allow-listing for the enterprise.

6. Keep a human accountable for consequential actions

Article 14 of the EU AI Act requires that people overseeing high-risk systems can override outputs and interrupt the system through a stop procedure. Engineering teams can apply the same idea to any agent action with financial, legal, or safety consequences.

Bifrost does not execute tool calls returned by a model automatically. The application calls the tool execution API explicitly, so an approval step can sit in between. Agent Mode runs tools autonomously only when each one is listed in tools_to_auto_execute, and no tools are auto-executed by default.

For the stop procedure, an administrator can deactivate a virtual key, and inactive or expired keys are rejected for both LLM inference and MCP tool execution. The Bifrost MCP gateway write-up on access control and cost governance shows how these controls work together for agent fleets.

Data Protection and Traceability Principles

Principles seven and eight cover what flows through AI systems and what record it leaves behind. Data protection means inspecting prompts, responses, and tool payloads before sensitive content leaves the organization. Traceability means producing evidence of every request and every policy change, which is the engineering form of the EU AI Act's Article 12 logging requirement.

7. Inspect data in both directions

Users paste credentials and customer records into prompts, and models return content that violates policy. Inspection has to cover inputs, outputs, and agent tool payloads.

Bifrost Enterprise guardrails separate when to check (rules written in CEL) from how to check (reusable profiles). Three providers are Bifrost-managed: Prompt Guardrails, Custom Regex with a built-in PII Detection template, and Gitleaks-backed Secrets Detection. Twelve external integrations, including AWS Bedrock Guardrails, Azure Content Safety, Google Model Armor, and Microsoft Presidio, add further coverage.

Rules target either LLM traffic (before and after the provider call) or MCP tool executions (arguments before the tool runs, results after). Matches can be blocked or redacted, and redaction can apply at runtime, to logs only, or with reversible placeholders.

8. Make every request and every policy change traceable

Auditors ask two questions: what did the AI system do, and who changed the rules governing it. A complete record answers both, in storage the organization controls.

Request logs are written asynchronously, so recording adds no request latency. Audit logs cover configuration and access changes rather than inference traffic, with configurable retention. Log exports keep searchable metadata in the database while payloads move to object storage.

This guide to AI audit trail controls for LLM traffic covers retention and review workflows.

Boundary and Shadow AI Principles

The last two principles define where governance applies. Principle nine keeps AI traffic, logs, and policy inside infrastructure the organization controls. Principle ten closes the gap that gateway-only governance leaves open: shadow AI, meaning desktop apps, browser tools, coding agents, and MCP servers that employees use outside any policy layer.

9. Keep data and control inside your boundary

Prompts, logs, and policy configuration are sensitive data in their own right, and regulated teams often cannot send them to a third-party control plane.

Bifrost for enterprises supports in-VPC deployments on AWS, Google Cloud, Microsoft Azure, Cloudflare, and Vercel, with no external network dependencies. Content logging can be switched off per virtual key, and audit logs can omit client IP addresses where employee privacy rules require it. The Bifrost Enterprise license adds VPC deployment, vault-backed key management, and clustering.

Inline enforcement stays cheap: Bifrost adds 11 microseconds of overhead per request at 5,000 RPS in sustained benchmarks.

10. Govern all AI usage, including shadow AI

A gateway governs only the traffic configured to pass through it. Desktop chat apps, browser AI, and coding agents with their own MCP servers carry no budget, guardrail, or audit trail unless something routes them.

The answer is AI Gateway + Bifrost Edge. The Bifrost AI gateway remains the control plane where virtual keys, budgets, guardrails, and audit logs are defined. Bifrost Edge, currently in alpha, runs on macOS, Windows, and Linux and routes endpoint AI traffic through that same gateway, so existing policies apply without per-app configuration.

Figure 3: The gateway stays the single policy engine; Bifrost Edge brings AI usage that was never configured to use it under the same controls.

Edge adds two decisions that only make sense on the endpoint. App governance lets administrators allow or block AI applications across the fleet, and new apps trigger an approval request in the admin console. MCP server governance inventories the MCP servers configured in each AI app and enforces per-server allow or deny decisions on the device. This piece on closing the last mile from AI gateway to endpoint covers rollout through MDM.

How to Roll Out AI Governance Best Practices

Roll out AI governance best practices in dependency order: inventory current AI usage, attach identity, restrict access, cap spend, add guardrails, then collect evidence and extend coverage to endpoints. Identity comes first because every later control is scoped to the identity on the request, and evidence comes after the controls it records.

Figure 4: Identity comes first because every later control, from budgets to audit evidence, is scoped to the identity on the request.

A practical sequence for a platform team looks like this:

• Inventory: list every application, provider key, coding agent, and MCP server in use, then route application traffic through the gateway.
• Identity: replace shared provider keys with one virtual key per application or team, and connect SSO.
• Access: set provider and model allow-lists and MCP tool allow-lists, starting from deny.
• Spend: set budgets and rate limits per team, using a month of request logs to size them.
• Guardrails: start with secrets detection and PII rules on inputs, then add output and tool-call rules.
• Evidence and coverage: enable audit logs and log exports, then extend coverage to employee machines with Bifrost Edge.

The Bifrost governance resource page shows the virtual key, budget, and rate-limit configuration for the first stages. For the conceptual model behind this sequence, see this AI governance explainer.

Frequently Asked Questions

What is an AI governance system?

An AI governance system is the combination of policies, assigned roles, and technical controls an organization uses to manage AI risk across the lifecycle. ISO/IEC 42001 calls this an AI management system. In engineering practice, the runtime part is usually an AI gateway that authenticates callers, enforces model and tool access, applies budgets and guardrails, and records request and audit logs.

What are the components of a governance framework?

A working AI governance framework has five components: principles that state commitments, roles that own decisions, controls that enforce the principles at runtime, evidence that records what happened, and a review cycle that updates policy as models and regulations change. The NIST AI RMF organizes this work under four functions: Govern, Map, Measure, and Manage.

How are AI governance principles different from responsible AI principles?

Responsible AI principles describe values such as fairness, transparency, privacy, and accountability. AI governance principles describe the operating commitments that make those values enforceable: an identity on every request, least-privilege access, spend limits, guardrails, and audit evidence. Governance controls are the mechanism through which responsible AI commitments get checked.

Which AI governance framework should an engineering team start with?

Most engineering teams start with the NIST AI RMF because it is voluntary, publicly available, and organized around functions that map to engineering work. Teams pursuing certification add ISO/IEC 42001, and teams placing high-risk systems on the EU market must meet the EU AI Act's logging and human oversight obligations.

What is shadow AI?

Shadow AI is AI usage that happens outside approved, governed channels: chat apps installed on laptops, AI features in the browser, coding agents in the terminal, and the MCP servers wired into those tools. It matters because a gateway governs only traffic configured to pass through it. AI Gateway + Bifrost Edge, currently in alpha, routes that endpoint traffic through the same Bifrost policies; this overview of shadow AI risks in enterprises covers detection.

What is LLM governance?

LLM governance is the part of AI governance that applies to large language model traffic: which applications and users can call which models, at what cost, with which content checks, and with what record. Because LLM calls travel over APIs, LLM governance is usually enforced at an AI gateway rather than rebuilt inside each application.

Put These AI Governance Principles Into Practice

AI governance principles become useful the moment they run as controls: virtual keys for identity, allow-lists for models and tools, budgets for spend, guardrails for data, and audit logs for evidence. Bifrost enforces all of them at the gateway, and Bifrost Edge extends them to employee machines. To map these principles to your environment, book a demo with the Bifrost team.