Key takeaways
- Graduated authority separates investigation from execution - you don’t have to treat all agent actions the same way.
- An approval is only useful if it describes the specific operation, target, and parameters about to run.
- Pre-approved (bounded) execution moves your decision earlier, not away from you; the service owner defines eligible actions in advance.
- Controls belong in the execution path, not in the model’s context. Deterministic policy enforcement, not model memory, is what blocks an out-of-scope action.
- Every level requires an action record: what ran, under which authority, what the result was, and who was involved.
When you’re responsible for service reliability, an agent that can investigate an incident is useful. An agent that can change production asks more of you. You need to know which changes it can make, when your team will be brought into the decision, and how to take control if the situation changes.
That doesn’t require a single answer for the whole agent. You might let it collect diagnostic information on its own, ask it to prepare configuration changes for approval, and permit a narrowly defined recovery action under conditions your service owner has already agreed to. Moring’s AI Ops agents are built around exactly this separation: investigate and recommend, act after approval, or complete a pre-approved action.
This is the purpose of a graduated authority model for AIOps. It lets you assign permission to the work being performed, with a clear distinction between recommending a change and executing it.
Three ways to handle a proposed action
The following model gives you a starting point for deciding how an agent’s work reaches production.
Recommendation
What the agent does: Investigates and proposes a change
Where your team decides: You assess the proposal and execute through your existing process
Record to retain: Evidence, proposed action, and the operator’s decision
Approval required
What the agent does: Prepares an operation and executes after approval
Where your team decides: An authorized reviewer approves the specific target and parameters
Record to retain: Approved operation, reviewer, validity period, and execution result
Bounded execution
What the agent does: Runs an operation covered by an existing permission grant
Where your team decides: Your service owner defines the eligible actions and conditions in advance
Record to retain: Grant used, checks performed, actions taken, and exceptions
These levels can coexist. They also needn’t form a ladder that every operation eventually climbs. If an action warrants human approval, repeated successful investigations don’t remove the reason for that approval.
The underlying approach is consistent with AGENTSEC04-BP02 in the AWS Well-Architected Agentic AI Lens, which defines risk-tiered human-in-the-loop approval: read-only operations proceed autonomously, low-risk writes require single-reviewer approval, and higher-risk operations require stricter approval paths. What matters in practice is whether the permission describes the specific operation about to run.
An approval needs to describe the change
The AWS Well-Architected guidance identifies a common anti-pattern worth naming directly: providing reviewers with only the proposed action, without the reasoning chain, data sources, or potential consequences, turns review into a formality. The approval request needs to make consequences visible.
An agent recommends restoring the previous configuration version for an API gateway service after detecting a 500-error spike. The approval request identifies the target service by name, specifies configuration version 2.4.1 (the last stable deployment), and includes the error-rate graph showing the correlation between the current version and the failure. Before approving it, you’ll want to see which downstream services share this configuration, whether the rollback affects only this gateway or propagates to dependent resources, and the evidence connecting version 2.4.2 to the incident.
You’ll also need enough information to judge the consequences. A proposal to change one service is a different decision from a proposal affecting every service that shares the configuration. The approval request should make that difference visible without requiring you to reconstruct the investigation from raw logs.
For this model, the resulting approval belongs to the specific operation for a defined period. If the agent changes the target or selects another version, the revised proposal returns to your team. Otherwise, the action could drift away from the one you reviewed while still carrying an “approved” status.
A timeout needs an explicit outcome too. If the reviewer is unavailable, your workflow can hold the operation and escalate to another authorized person. Silence doesn’t supply a decision.
What bounded execution would mean
Pre-approval moves your decision earlier. You agree on an operation pattern and the conditions under which it can run, rather than reviewing each matching occurrence.
For example, you could evaluate a recovery operation restricted to named resources and particular parameters. The grant would identify the required checks and the situations that return control to your team. “Resolve this class of incident” would be too broad to explain which changes are actually permitted.
This makes the evaluation more concrete. You can test whether the agent completes permitted operations and whether the surrounding controls block actions outside the grant. You can also examine what happens when a required check is unavailable.
The control belongs in the execution path. The AWS guidance is specific here: risk classification should use deterministic logic (policy engines, rule-based classifiers) as the authoritative signal. An LLM exposed to the same untrusted content as the request being evaluated could be influenced by adversarial content into misclassifying the risk level. Asking the model to remember its permission limits is not an independent check.
The enforcement point sits between the agent’s tool call and the system that will execute it. The agent proposes an action. The policy engine evaluates that proposal against the current grant, checks the required conditions, and either permits the call to proceed or blocks it before any state changes. This means your control logic never depends on the agent’s cooperation. A misconfigured prompt or a model failure cannot bypass the check.
You also need a plan for partial completion. If a bounded operation involves multiple steps and a mid-operation check fails, the workflow must either roll back the completed steps or hand off to a human operator with a clear record of what has already changed. Leaving a service in an intermediate state because a permission check expired halfway through is worse than blocking the operation at the start. Your grant definition should specify whether multi-step operations are atomic or whether they can pause for review after each stage.
Expanding authority without losing track of it
Before widening a grant, work through this checklist:
- Does your evaluation include the new action types the expanded grant would permit?
- Have you tested what happens when a required check is unavailable or returns an unexpected result?
- Is the grant scoped to a specific command, parameter shape, or resource - not a whole operation class?
- Is the grant auditable and revocable, with a defined review cadence for higher-risk tiers?
- Does the action record let you identify the grant used, the operation attempted, its result, and any handoff?
The AWS guidance flags wildcard trust grants - approving all future operations of a given type with no parameter scoping - as effectively removing human oversight from an entire class of operations. Expanded grants should be bounded and re-confirmable, not open-ended.
Before you widen a grant, the evidence should address the new authority you’re considering. Accurate incident summaries tell you something about investigation quality. They don’t show whether the system handles interrupted writes, changed service conditions, or an unavailable recovery procedure.
Your evaluation can include those situations and record how the workflow responds. The service owner then has a basis for approving a larger scope, keeping the existing one, or narrowing it.
The action record connects these decisions to what actually happened. It should let you identify the grant or approval used, the operation attempted, its result, and any handoff. During an incident, that gives your team a way to understand what the agent has already done before choosing the next step. The question of who is accountable for each entry in that record - who initiated, which agent acted, who owns it, who approved - is covered in more depth in Who is accountable when an AI agent makes a bad decision?
A useful authority model makes those choices predictable. You know which work can proceed independently and which decisions will come back to you, with the evidence needed to make them.
If you’re scoping this for a production incident workflow, the AI Ops workshop is a structured way to map which actions belong at each level, identify the approval owners, and define the action record before the agent goes live. The AI Control Plane enforces those decisions at runtime.
Frequently asked questions
What is a graduated authority model for AIOps?
It’s a way of assigning permission to the work an AI agent performs, rather than treating all agent actions the same. Investigation and recommendation can proceed independently; configuration changes require human approval; and a narrow set of pre-agreed recovery actions can run under conditions the service owner has defined in advance.
Why isn’t “human in the loop” enough on its own?
Routing every agent action through human review creates reviewer fatigue and rubber-stamp approvals. The goal is to focus human judgment on the decisions where it actually changes the outcome - which requires a risk classification layer, not just an approval step on everything.
What should an approval request include?
At minimum: the specific target and parameters, the evidence connecting the proposed change to the incident, the consequences of the change (including blast radius), and a defined validity window. An approval that doesn’t describe the specific operation is not a meaningful control.
What is a bounded execution grant, and how is it different from an approval?
An approval is a per-operation decision. A bounded execution grant is a pre-authorization: the service owner evaluates a pattern of operation in advance and agrees that matching actions can run without per-occurrence review, provided defined checks pass. The grant must be scoped to a specific command, parameter shape, or resource - not an entire operation class.
Where does the AI Control Plane fit in this model?
The AI Control Plane enforces the authority model at runtime. It evaluates agent identity and the requested action against policy before any tool call reaches a real system, pauses for human approval when required, and retains the action record across all three levels.