AI agent governance in production: how to govern any agent

TL;DR

• Production governance should apply to every agent you run, regardless of its model or execution harness. A change of agent should not require a new approval policy.
• Keep reading evidence, proposing a change, executing it, and escalating to a human as separate states. Each state needs its own controls.
• Bound what an agent can read and change. An instruction to “ask before acting” cannot enforce a gate if the agent already holds credentials that can make the change. Record evidence and decisions in an investigation timeline.
• Expand execution rights only after supervised runs show that the agent handles routine actions correctly. Mezmo Governance is a separate, closed-beta product for applying these controls to any agent.

AI agent governance in production is the set of permissions, approval gates, and audit records that decide what an agent can read, propose, and change. Enforce those rules outside the agent so they hold when you change agents.

Why governance can't depend on which agent you pick

An SRE team may use one agent to investigate alerts and another to manage deployments. Either agent could encounter the same failing service, but the team's rules for changing that service should stay the same. If approval rules live only inside the alert agent's harness, a deployment agent can take a different path to the same production action.

Keep production policy independent of the agent that requests an action. For example, a rule might let agents read service telemetry but require an SRE to approve a customer-facing rollback. Keeping the rule outside each harness lets you change models or agents while retaining the same approval requirement. Write those rules against the production tools themselves, such as an MCP server’s rollback tool, rather than one agent’s built-in shell, so they still match when the agent changes. The boundary must also hold at the tools and credentials the agents use. A policy written outside the harness offers little protection if an agent still holds unrestricted production access.

AURA is Mezmo’s open-source SRE Agent for Production, built to help SRE teams manage production environments. You might use it to investigate an incident, but you should apply the same approval policy to any other agent that can act on your services. AURA is one agent choice, not a requirement for governing production access.

The read-propose-execute-escalate model for production agents

The read-propose-execute-escalate model separates evidence access from permission to change production. Give the agent a defined path to escalate decisions it cannot make. A suspected bad deploy shows why. The agent can inspect error rates and deployment history without gaining permission to roll back a release. If a tool treats the agent’s diagnosis as an instruction to act, a mistaken diagnosis can become a production change before anyone reviews it.

In the read state, the agent gathers evidence without changing production. For the suspected deploy, it compares errors before and after the release and checks which services changed. Governance controls which sources the agent can see and records the evidence behind its finding. Read access should not silently include tools that modify a service. Logs, tickets, and alert payloads can also contain attacker-controlled instructions. Treat them as evidence, not commands, and check any action the agent proposes against independent policy before execution. OWASP's prompt-injection guidance describes the risk of untrusted content steering an agent.

In the propose state, the agent describes an action for review. It might recommend rolling back the release, identify the affected service, and explain which observations support that recommendation. A reviewer can then reject the proposal if the errors began before the deploy or approve it if the evidence holds. A proposal remains a recommendation until a separate approval and permission check authorize execution.

In the execute state, the agent makes an authorized change within a defined scope. Approval to roll back one service should not grant permission to change other services or run unrelated commands. The agent moves to escalate instead when the proposed action exceeds that scope, the evidence conflicts, or the required approver is unavailable. Governance routes the investigation and proposed action to a person who can decide what happens next. Escalation does not itself authorize the change.

Setting bounded permissions before an agent touches production

Before an agent investigates a production incident, give it access to the evidence it needs and no authority to change the service. Scope its telemetry credentials to the relevant services and environments. Limit tool calls to approved endpoints, and check whether a tool can write to production even when the agent calls it for an investigation.

Set change permissions by the effect of an action, not by which agent requests it. Reading logs does not change a service, while restarting a pod does. A rollback or scale change can affect an entire service, so each needs its own scope, including the target resource and any approval requirement. Apply those boundaries to AURA or any other agent through credentials and action checks that you control outside the agent’s instructions. Keep policy-editing rights off every credential the agent can read. An agent that can edit its own policy can remove its own gates. OWASP calls excess permissions or autonomy excessive agency. The control is to limit what each tool and credential can do, not merely to ask the agent to behave.

Keep proposal rights separate from execution rights. An agent with read access can recommend a rollback and attach the evidence behind it, but the rollback tool should reject its request until the required approval and permissions are in place. An instruction to “ask before acting” cannot enforce that boundary if the agent already holds credentials that can perform the action.

Enforce least privilege where tools and credentials meet the production service. One pattern routes MCP tool calls through a policy gateway that checks the requesting agent's identity, approved action, target, and expiry before releasing a short-lived scoped credential. RBAC on the target system remains a backstop. A gateway cannot protect a second tool path that still accepts a broad shared credential, so test every route to a write and confirm the policy check covers every tool the agent can call, not only the ones you expect it to use.

Test the boundaries before connecting the agent to live operations. Check that it can read permitted evidence, cannot reach unrelated services, and cannot turn a proposal into a change through another tool path. Review the scopes when you add tools or services, since a new connection can give the agent more reach than its original permissions suggest.

Limit the blast radius of authorized writes as well. For example, permit no more than one restart for a named service in a defined window, and require a fresh review if the agent asks to repeat it or touch another service.

Approval gates for routine versus novel or high-risk actions

Production approval gates should reflect an action's blast radius and the evidence that the agent handles it correctly. Once supervised runs verify a routine action within a defined scope, you can use a shorter approval path for that action. For example, an agent investigating a known-flaky pod could propose a restart within one named service. Your on-call engineer can review the supporting telemetry, approve that single restart, and check whether the pod recovers. An approval for one restart should not authorize the agent to restart other pods or repeat the action without review.

A schema change or customer-facing rollback needs a different gate because it can affect more services or data. Require the agent to present the evidence, expected effect, and recovery plan to the service owner or designated change approver. Keep execution blocked until the required people approve the specific proposal. If the agent cannot establish the likely effect, route the decision to a human rather than treating a plausible diagnosis as permission to act.

Approval gates also need deadlines. You can set a short expiry for a pod restart proposal because a fresh alert may warrant a quick decision, while a schema change can follow your normal change process. Record when the agent opened the investigation, submitted the proposal, received an approval, and executed or escalated the action. When a proposal expires, require the agent to refresh its evidence before anyone approves it. Never let an agent approve its own proposal or another agent's proposal for a protected change. Repeated, context-free approval requests encourage rubber-stamping, so group only genuinely repeatable low-risk actions into a verified routine tier and show the reviewer the evidence and exact effect. That prevents an engineer from authorizing a restart or rollback based on an incident state that has already changed.

‍

These are starting policies, not universal permissions. The target service, rollout conditions, and blast radius determine the actual approval gate.

Audit trails that hold up after the incident is over

An audit trail should let you reconstruct the full investigation, not just the command an agent ran. For each evidence read, record the agent’s identity, the time, the source, and the query or tool call. Preserve a reference to the evidence the agent saw, along with its version or collection time, so a later change to a dashboard does not erase the basis for its decision. Give each agent its own identity, such as its own service account, rather than one account shared across agents.

For each proposal, record the agent’s stated reasoning and the decision that followed. Link the proposed action to its evidence, expected effect, affected service, and the permission and approval rules in force at the time. If someone approves execution, capture who approved it, when, and the exact action and expiry authorized.

Record the command the agent actually issued and the system’s response separately. That distinction lets you see if an approval for a restart was followed by a different action, such as a rollback.

Escalations need their own entries, including the reason the agent stopped, the person or queue it contacted, and how long the proposal waited. Keep these events on one timestamped investigation timeline, including rejected and expired proposals. After an incident, you can then check whether the agent used sound evidence, stayed within its permissions, and followed the required approval path. Those findings give you a basis for deciding whether to expand its authority later.

An AI agent audit log should capture:

• Agent ID, timestamp, source, query or tool call, and evidence reference with collection time or version.
• Proposal, rationale, target service, expected effect, and policy version.
• Approver identity, decision, exact authorized action, and approval expiry.
• Issued command, execution time, system response, and outcome.
• Escalation reason, recipient, and elapsed time, including rejected or expired proposals.

Earn autonomy. Don’t grant it.

Earn autonomy. Don’t grant it. Expand an agent's production authority only after its investigation records show sound decisions within a defined scope. Default permissions cannot tell you whether the agent interprets your alerts correctly or recognizes when a runbook does not fit. Compare its proposals with on-call decisions, including proposals engineers reject.

Start with approved read access and supervised proposals. The agent may examine evidence and recommend an action, but a person approves execution or handles an escalation. Record what the agent read, why it proposed the action, what the reviewer changed, and whether the fix worked.

Consider moving a specific routine action to post-action review only after supervised records show that the agent selected it under the right conditions and that approved executions had the expected result. For example, you might let the agent restart a known-flaky pod in one service, then review every restart afterward. Check whether it followed the runbook, used the right evidence, and restored service. Keep rollbacks and unfamiliar actions behind prior approval.

If post-action reviews continue to show correct behavior within that scope, keep routine execution under ongoing audit review. Require escalation when evidence is missing, an action falls outside its permitted scope, or the outcome differs from expectation. If the agent misses a warning sign or makes a harmful change, remove that execution permission and return the action to propose-only. Separate read, propose, execute, and escalate permissions let you narrow its authority without stopping useful investigations.

How Mezmo Governance applies this to any agent

Mezmo Governance puts one policy in front of every agent you register. Before a tool runs, the agent sends Governance the tool name, the MCP server it belongs to, and the exact arguments. Governance answers allow, deny, or wait for an approver.

Rules can match on arguments, so a rollback in production can require approval while the same tool in staging runs. A call that doesn't match a rule gets the policy's fallthrough. If Governance denies the call or doesn't answer, the tool doesn't run.

Approvals go to people with the policy's approver role, in Mezmo or Slack. Governance prevents agents from approving their own proposals or another agent's protected changes. Automated callers cannot approve or deny requests, and approvals apply only to the specific call they were granted for. Requests that aren't approved in time expire, requiring the agent to submit a new request.

Teams can also test policies before connecting agents to live operations. Mezmo Governance supports policy test suites and draft evaluations, including test cases saved from real decisions. This lets teams check proposed policy changes against known tool calls before putting them into effect or expanding an agent's authority.

Each decision is recorded with the agent, the policy revision it was evaluated against, who approved it, and, when supplied, the agent's reason for the call. Governance decides whether a call may run. Scoped credentials and RBAC on the target system still limit what an approved call can access.

When evaluating Mezmo Governance, check that a rollback still requires approval after you change agents, that policy changes can be tested before deployment, and that decision records show the exact tool call, policy revision, and approver.

A governance policy should stay in force when a team changes agents, whether that's AURA or another agent with access to production tools.

FAQs

What is AI agent governance?

AI agent governance is the policy and enforcement layer that controls what an agent can read, propose, and change, and records who approved any protected action.

How do I stop an AI agent from changing production without approval?

Remove unrestricted write credentials from the agent and enforce approvals at the tool or credential boundary. Reject a write unless the requesting identity, action, target, and approval all match.

What should an AI agent audit log include?

Record agent identity, time, evidence source and version, proposal and rationale, approver, authorized action and expiry, issued command, and system response.

Do SRE agents need human-in-the-loop approval?

Require human-in-the-loop approval for novel or high-risk changes and for routine actions until supervised results justify a narrower review path. Read-only investigation can proceed without an approval for every query.

How is agent governance different from RBAC or an agent’s built-in permissions?

RBAC limits what a credential can do in a target system. Agent governance adds decisions about when an action is allowed, who approves it, and what evidence must accompany it. Both controls matter because an agent with broad RBAC access can bypass an instruction in its prompt to ask first.

Will approval gates slow down incident response?

Approval gates add a review step where you require one, but they need not hold up every investigation. An agent can read telemetry and prepare a proposal while an engineer handles the incident. You can set faster review paths for verified routine actions and require explicit approval for novel or higher-risk changes.

Which actions should start in the routine tier?

Start with narrowly scoped actions your engineers already perform under a documented runbook, such as restarting a known-flaky pod in one service. Check past incidents, define the conditions that permit the action, and keep approval in place until the agent’s proposals and outcomes match your expectations. A customer-facing rollback should take a separate approval path because it affects a wider set of users.

Does Mezmo Governance require AURA?

No. Mezmo Governance is a separate, agent-agnostic closed-beta product, not an open-source component of AURA. AURA is Mezmo's open-source SRE Agent for Production and one example of an agent a team could govern.

Before you connect an agent to production

Before an agent joins the incident path, a platform or SRE lead should check seven controls:

1. Fail closed: If a policy check errors or times out, the action doesn't run.
2. Set a default policy: Configure the policy's fallthrough to deny or require approval so that tools without a matching rule can't run unreviewed.
3. Enforce least-privilege access: Give each agent a distinct identity and access only to the evidence it needs.
4. Separate permissions: Distinguish between read, propose, execute, and escalate permissions across every tool path.
5. Require human approval: Require a human decision for novel or higher-risk changes. Prevent agents from approving their own actions or modifying the policies that govern them.
6. Limit approved actions: Restrict each approved action by target, expiration, and execution rate.
7. Maintain an audit trail: Record the evidence, approval, command, and outcome on a single investigation timeline.