An alert fires shortly after a deployment. Error rates are rising, one service is consuming more memory than usual, and customer requests are beginning to fail.
An AI operations agent examines the deployment history, traces the affected dependencies and compares the incident with previous failures. It concludes that a particular service is probably responsible and proposes restarting it.
The recommendation appears reasonable. Waiting for an engineer may extend the outage. Restarting immediately may restore service.
Should the agent act?
This is a hypothetical scenario, but the decision is already becoming real for operations teams. It captures the central AgenticOps question. The issue is not simply whether an AI system can investigate an incident or execute a command. It is how much authority that system should receive, and what must be true before its authority increases.
My view is that AgenticOps is already useful, but the public evidence supports a narrower form of autonomy than many headlines suggest. Enterprises are seeing value from agents that collect evidence, correlate events, investigate likely causes and enforce release policies. Evidence for broad, unattended control of production infrastructure remains limited.
That does not make AgenticOps an empty technology trend. It means we need to evaluate it as an authority model, not merely as a smarter automation tool.
Adoption is real, but adoption does not describe authority
Cisco’s September 2026 AgenticOps report presents an important market signal. The underlying Omdia study surveyed more than 1,000 IT and network operations leaders from organisations with at least 500 employees across North America, Western Europe and Asia Pacific.[1]
Fifty-one per cent reported having agentic systems that act in production. Separately, 82 per cent said they were comfortable allowing at least some production network changes without prior approval.
Those numbers show that operational agents are moving beyond experiments. They do not tell us how much authority those agents currently hold.
“Acting in production” can describe very different arrangements. An agent may gather logs, open an incident, recommend a rollback, block a risky release or execute a predefined recovery step. Each activity touches production operations, but the risk is not the same.
The trust findings expose that difference. Sixty-nine per cent of respondents required detailed explanations for agent-driven actions. Ninety-nine per cent wanted at least one guardrail, such as approval gates, policy limits, role-based access, audit trails or emergency overrides.[2]
The market signal is therefore more nuanced than “enterprises are handing operations to AI.” Organisations appear willing to increase automation while demanding stronger controls over what an agent can see, decide and change.
The scope also matters. This study concerns network operations leaders. It is useful evidence about NetOps attitudes and reported deployment. It is not a universal measurement of every enterprise workload.
An agent can choose a step without owning the decision
Traditional automation follows a path that engineers define in advance. A script restarts a service when a threshold is crossed. A deployment pipeline runs a fixed sequence of tests. A runbook executes known commands in a known order.
An operational agent is different because it can interpret context and select among possible tools or actions. It may decide which logs to query, which dependency to inspect or which recovery playbook best matches the evidence.
That flexibility is valuable when incidents do not follow a predictable sequence. It is also why authority must be treated separately from intelligence.
A model’s confidence is a prediction. It is not an access-control decision.
An agent may be highly confident that restarting a service will resolve an incident. That confidence does not establish that the agent is permitted to restart it, that the action is safe in the current environment or that someone has accepted responsibility for the consequences.
AgenticOps therefore combines two different systems:
- A reasoning system proposes what should happen.
- An authority system determines what is allowed to happen.
The agent may select among pre-authorised tools and steps within a defined task boundary. It should not expand that boundary or decide how much authority it deserves.
What current product evidence demonstrates
The strongest current documentation points in a consistent direction. Useful operational agents work within explicit resource, permission and approval boundaries.
| Evidence | Documented behaviour | What it supports | What it does not prove |
|---|---|---|---|
| Cisco and Omdia NetOps study [1][2] | Reports production adoption, willingness to allow some autonomous changes and strong demand for guardrails | AgenticOps is a real NetOps trend, and trust controls remain important | Independent proof that broad autonomy is safe |
| AWS DevOps Agent security documentation [3][4] | Uses Agent Spaces, IAM roles, permission guardrails, read-only defaults and audit records | Useful investigation depends on a defined access boundary | That unrestricted write access is appropriate |
| Azure SRE Agent documentation [5] | Separates resource permissions from Review and Autonomous run modes | Access rights and approval policy should be governed independently | That autonomous mode is suitable for every production task |
| Google SRE walkthrough [6] | Retrieves evidence, selects from mitigation playbooks and verifies the outcome | A credible action pattern includes a closed action set and verification | A measured production result at scale |
These sources are not equivalent. The Cisco report is a Cisco-sponsored market study conducted by Omdia. AWS and Microsoft describe product controls. Google’s walkthrough is an architectural example rather than a measured customer result.
Even with those limits, the pattern is clear. Public evidence is strongest for investigation, correlation, summarisation, release gating and carefully bounded action. It is much weaker for unrestricted changes across production systems.
This pattern led me to a more useful way of discussing AgenticOps. The choice is not between manual operations and full autonomy. It is a ladder of operational authority.
The Agent Authority Ladder
For accessibility, the framework is also provided below.
- Observe: The agent collects and normalises telemetry. People define the trusted sources and access boundaries.
- Investigate: The agent correlates evidence and tests possible explanations. People review uncertainty and challenge conclusions.
- Recommend: The agent proposes a runbook, remediation or release verdict. People accept, reject or modify the recommendation.
- Approved action: The agent executes one clearly described change after approval. A responsible operator assesses the impact and authorises it.
- Bounded autonomy: The agent executes a predefined and reversible class of action. People set the policy, monitor behaviour and retain override authority.
Moving from one level to the next is not simply a model upgrade. It is an organisational decision about permissions, risk and accountability.
A team may trust an agent to investigate every production incident while allowing it to execute only a small set of actions. Another team may permit automatic restarts for stateless development services but require approval for the same action in a payment system.
The model might be identical in both environments. The appropriate authority is not.
Returning to the restart decision
Before the agent acts on the service restart from the opening scenario, four questions need answers.
1. Does it have enough operational context?
A recommendation based on one error log is very different from one supported by deployment history, dependency topology, resource metrics, recent configuration changes and similar incidents.
An agent cannot compensate for missing telemetry by reasoning more confidently. Observability maturity therefore comes before operational autonomy. If ownership, dependencies and incident history are fragmented, the agent inherits that fragmentation.
2. Is the action explicitly permitted?
The agent should operate through a constrained identity with least-privilege access. Its tools, target resources and permitted actions should be defined outside the model. A prompt telling the agent to “be careful” is not a security control.
AWS documents this separation through Agent Spaces, IAM roles and permission guardrails. Microsoft offers a useful comparison in Azure SRE Agent by separating resource permissions from the run mode that decides whether infrastructure actions need approval.
The products differ, but the durable principle is the same. Capability and permission must be governed independently.
3. Is any required approval informed?
Before approving the restart, an operator should see:
- The evidence supporting the diagnosis.
- The exact action being proposed.
- The systems and users that may be affected.
- The expected recovery signal.
- The rollback or alternative response.
- The conditions that determine success or failure.
If the operator cannot understand those points, approval becomes a ritual. A button does not create meaningful human control when the person pressing it lacks the evidence, time or authority to judge the action.
The OWASP Top 10 for Agentic Applications 2026 provides a broader security warning around excessive agency.[7] The practical lesson for operations is simple. High-impact tools need stronger permission boundaries than low-risk investigation tools.
4. Can the outcome be verified?
Executing a command is not the end of an operational action. The system must confirm whether error rates fell, traffic recovered, dependencies stabilised and customer impact ended.
If recovery cannot be established, the agent should roll back where possible or escalate with the evidence it collected. Without that loop, an agent can mistake successful command execution for successful incident resolution.
Human approval is not always the safest answer
It is tempting to solve every AgenticOps risk by requiring a person to approve every action. I do not think that is sustainable.
During a fast-moving outage, an approval request may sit unanswered. An exhausted engineer may approve it without reviewing the evidence. Requiring human confirmation for hundreds of low-risk actions can create alert fatigue and reduce the quality of oversight where it genuinely matters.
In some environments, bounded autonomy may be safer than delayed human intervention. Restarting a stateless worker, scaling a predefined service tier or pausing a faulty deployment can be appropriate when the action is repeatable, observable and reversible.
The goal is not to insert a human into every execution path. It is to match authority to the action.
| Delegate earlier when the action is | Keep explicit approval when the action affects |
|---|---|
| Repeatable and well understood | Identity or access control |
| Small in blast radius | Firewall and network security policy |
| Observable before and after execution | Production databases or persistent data |
| Reversible through a tested path | Destructive storage operations |
| Safe to repeat without compounding harm | Shared infrastructure with unclear ownership |
| Covered by policy and complete audit records | Regulated or compliance-sensitive systems |
This is a starting point, not a universal permission list. The same action can carry different risk in different systems.
Agent authority does not remove human authority
An agent can receive permission. It cannot accept organisational accountability.
Someone must decide which evidence sources are trusted, which tools are available, which environments can be changed and which failures require escalation. A named service owner remains responsible for the policy, even when the agent operates within it correctly.
The division should be explicit. The agent works within its assigned task boundary by collecting evidence, explaining its reasoning, selecting from permitted actions and reporting the result. Human authority creates that boundary, approves high-impact exceptions, reviews failures and decides whether permissions should expand, remain unchanged or be reduced.
This is why “human in the loop” is too vague to serve as a governance model. The important question is not whether a human appears somewhere in the workflow. It is which decisions remain human decisions.
Faster resolution is not the complete scorecard
Lower mean time to resolution is useful, but MTTR is not a trust measure.
A system can reduce resolution time by acting aggressively, escalating fewer cases or declaring recovery before the underlying problem has been removed. An incident may close quickly and return an hour later.
| Measure | What it reveals |
|---|---|
| Time to useful evidence | Whether the agent accelerates investigation |
| Recommendation acceptance rate | Whether engineers find its conclusions useful |
| Abstention quality | Whether it recognises insufficient evidence |
| Human override rate | How often operators reject or interrupt its decisions |
| Rollback success rate | Whether failed actions can be recovered safely |
| Incident recurrence | Whether the action fixed the cause or only the symptom |
| Policy violation rate | Whether the agent remained inside its authority |
| Audit completeness | Whether investigators can reconstruct what happened |
A strong pilot should improve speed without weakening these safety and quality measures.
Where teams should begin
The safest starting point is not autonomous remediation. It is operational understanding.
Let agents observe first. Give them access to approved telemetry, deployment records, incident history and service documentation. Measure whether they retrieve the right evidence and whether their summaries are accurate.
Then allow them to investigate and recommend. Compare their conclusions with those of experienced engineers. Record when the agent is correct, when it abstains and when it produces a confident but incomplete explanation.
Approved action should follow only when the recommendation process has become dependable. Even then, begin with narrow, reversible changes and require the system to state the expected result before execution.
Bounded autonomy should be earned per action class. It should not be granted broadly because a model performed well on a different task.
An agent that reliably restarts stateless workers has not demonstrated that it can alter firewall policy. An agent that reviews deployments has not earned permission to change database schemas. Authority should expand through specific evidence, not general confidence in the technology.
Trust is earned one bounded decision at a time
Return once more to the proposed service restart.
The agent may be allowed to execute it without waiting for an engineer, but only if the organisation has already determined that this class of restart is permitted, reversible and verifiable. The agent should not invent that authority during the incident.
If dependencies are unclear, the blast radius is uncertain or recovery cannot be measured, the correct action may be to recommend and escalate. That is not an AgenticOps failure. Knowing when not to act is part of operational competence.
The market is moving quickly, and operational agents will receive greater authority as their capabilities improve. The organisations that benefit most will not be those that remove approval gates fastest. They will be those that understand why each gate exists, when it can safely be removed and how the remaining controls will detect failure.
AgenticOps is not about removing people from operations. It is about deciding carefully and explicitly which decisions an agent may make, which require approval and which should remain human.
References and further reading
Sources and documentation reviewed on 28 September 2026. The opening incident is an illustrative scenario rather than a single customer outage report.
- The Impact of Agentic AI on Network Operations, Cisco and Omdia, 2026. Research report surveying 1,000+ NetOps leaders across North America, Western Europe and Asia Pacific on adoption, autonomous actions and guardrail demand. ↩
- NetOps Is Already Deploying Autonomy. Trust Will Decide How Far It Goes, Cisco, September 2026. Cisco’s operational analysis of the survey findings and the trust requirements surrounding autonomous network actions. ↩
- AWS DevOps Agent Security, AWS, reviewed 28 September 2026. Official documentation covering Agent Spaces, identity isolation, operational data handling, journals and audit trails.
- Limiting Agent Access in an AWS Account, AWS, reviewed 28 September 2026. Technical guidance on IAM roles, permission guardrails and effective access controls.
- Run Modes in Azure SRE Agent, Microsoft, reviewed 28 September 2026. Architecture documentation demonstrating the separation between resource permissions and Review versus Autonomous execution modes.
- How Google SREs Use Gemini CLI to Solve Real-World Outages, Google Cloud, January 2026. Practical walkthrough demonstrating evidence retrieval, closed playbook mitigation, human approval and outcome verification.
- OWASP Top 10 for Agentic Applications 2026, OWASP GenAI Security Project, December 2025. Security guidance detailing excessive agency and the necessity of strict operational privilege boundaries. ↩
- AI Risk Management Framework (AI RMF 1.0), NIST, reviewed 28 September 2026. Federal foundational standard for managing risks in artificial intelligence systems.