AI Agent Governance: 7 Production Best Practices (2026)
Seven battle-tested practices for governing AI agents in production — audit trails, approval gates, budgets, RBAC, data residency, and kill-switches.
What you will learn
- Apply 7 governance best practices to your AI agent fleet
- Understand the governance pyramid: visibility, control, compliance
- Design policy hierarchies that scale across teams and tenants
- Know the common governance anti-patterns and how to avoid them
TL;DR — Governance is a pyramid, not a checklist. Build visibility first (audit trails), then control (approvals, budgets, kill-switch), then compliance (RBAC, data residency, evidence). Skipping straight to compliance is the #1 reason audits fail for AI-heavy teams.
The Governance Pyramid
Agent governance is not a single checkbox — it is a pyramid. The foundation is visibility (can you see what agents are doing?), the middle layer is control (can you stop them?), and the top is compliance (can you prove it to auditors?).
Most teams skip straight to compliance and wonder why audits fail. You cannot prove control you do not have, and you cannot control what you cannot see.
Every governance failure I have seen in production traces back to a missing log line someone thought would never be needed.
1. Maintain an Immutable Audit Trail
Every agent action should be logged to an append-only store. Not just what happened, but who triggered it, which model was used, how many tokens were consumed, and what the output was. This is your foundation for everything else.
An audit trail you can edit is not an audit trail — it is a suggestion. Use append-only storage, version fields, and WORM-style retention with at least 365 days of history.
Dobby logs every agent action to an immutable audit trail with 365-day retention. Every LLM call, every tool use, every approval decision — all queryable, all exportable for auditors.
2. Require Human Approval for High-Risk Actions
Not every action needs approval. Reading a file is low risk. Deploying to production is high risk. Configure approval gates based on the impact of the action, not just the agent performing it.
Good rules of thumb: any write to production, any action above a cost threshold, any touch of regulated data, and any change to security policy should pause for review. Everything else should run freely.
3. Set Token Budgets Per Agent
A single misconfigured agent can burn through thousands of dollars in hours. Set daily and monthly token budgets per agent, per tenant, and per organization. Alert at 80%, warn at 90%, block at 100%.
An agent enters a retry loop at 2 AM. No budget. By 8 AM you have spent $7,400 on a single Claude Opus chain.
Same loop, $50 daily budget. At $40 a Slack alert fires. At $50 the agent is blocked automatically. Damage capped at one cup of coffee.
4. Restrict Models by Policy
Not every agent needs Claude Opus or GPT-4o. A summarization agent works fine with Haiku or GPT-4o-mini. Restrict which models each agent can use — this reduces cost and limits the blast radius of a compromised agent.
5. Enforce Data Residency
If your organization operates under GDPR, SOC 2, or similar frameworks, agent data must stay within designated regions. Choose your region at workspace creation and ensure no agent call crosses boundaries — including the LLM provider endpoint.
6. Implement Role-Based Access Control
Not everyone should be able to configure agents, approve actions, or view costs. Use a 3-level RBAC hierarchy: Platform admins set global policies, Organization owners manage their org, Tenant members work within their workspace — with role-specific permissions.
7. Have a Kill-Switch Ready
When something goes wrong — and it will — you need to stop everything instantly. A kill-switch should propagate within seconds, be scoped (all traffic, LLM only, or new keys only), and leave an audit record of who activated it and why.
Anti-Patterns to Avoid
- Governance-in-Confluence — policies nobody reads and nothing enforces.
- Per-framework dashboards — five tools to answer one question.
- Shared API keys — cannot attribute cost, cannot revoke safely.
- Silent auto-approve-everything — the audit trail looks clean, the risk is hidden.
- Manual offboarding — ex-employees keep agent access for weeks.
Governance is ad-hoc. Policies live in Confluence docs nobody reads. When an agent misbehaves, the team scrambles to find the off switch. Audit prep takes weeks.
Governance is enforced by the platform. Policies are code. Every action is logged automatically. Kill-switch stops everything in 5 seconds. Audit prep is a query.
All 7 practices are built into Dobby as platform features — not add-ons. Audit trails, approval gates, budgets, model restrictions, data residency, RBAC, and kill-switch are available on every plan.
Frequently Asked Questions
What is the difference between AI governance and AI agent governance?
AI governance covers model selection, bias, training data, and evaluation. AI agent governance is the runtime layer — the controls that shape what the agent is allowed to do, log, and spend once it is live in production.
How long should I keep agent audit logs?
At minimum 365 days. SOC 2 and most enterprise customers expect at least one full audit cycle of evidence. GDPR requires sufficient retention to demonstrate lawful processing; 12-24 months is common.
Do I need approval gates if the agent is read-only?
Usually not for the action itself, but consider gates for any agent that can exfiltrate data — large exports, cross-region reads, or queries on regulated datasets should still pause for review.
Can I start with just a kill-switch and add the rest later?
A kill-switch without visibility is panic without information. Start with audit + budgets, then add approvals and the kill-switch. Compliance controls come last, once the operational pieces are stable.