From Copilots to Autonomous Agents: A Maturity Model for Operations

Every vendor briefing this year promises an AI copilot. Almost none of them explain how a suggestion engine becomes a system that can be trusted to open a change ticket, roll back a bad deployment, or contain a compromised host at 3 a.m. without waking anyone up. This article lays out a five-level maturity model for agentic operations — the architecture, guardrails, metrics, and operating-model changes that separate a chatbot bolted onto a ticketing queue from an autonomous agent that plans, acts, and verifies its own work.

The copilot ceiling: why assistance doesn't scale operations

Copilots earned their place in the operations stack quickly. They summarize alerts, draft runbooks, translate stack traces into plain English, and cut the time an analyst spends orienting themselves before they act. For a workforce drowning in alert volume, that time savings is real and it shows up in engagement surveys and analyst retention numbers within a quarter. But copilots share a structural ceiling: a human has to read the suggestion, judge whether it's correct, and execute it. The AI never closes the loop. It never learns whether its own suggestion actually fixed anything, because it never watches the outcome.

That ceiling matters more than most roadmaps admit. IT operations and security operations are not knowledge-retrieval problems dressed up as workflows — they are closed-loop control problems. An overloaded disk volume, a certificate about to expire, a lateral-movement pattern in EDR telemetry: each of these has a correct sequence of diagnostic and corrective actions, a verification step to confirm the fix held, and a rollback path if it didn't. A copilot that only drafts the recommended command still leaves the entire control loop — act, observe, verify, adapt — sitting on a human's desk. At enterprise alert volumes, that desk is the bottleneck, not the model.

The evidence shows up in the metrics leaders actually track. Mean time to resolve barely moves when copilots are deployed in isolation, because drafting an answer faster does not shorten the queue of approvals, context switches, and manual execution steps that follow. Alert fatigue doesn't improve either, because a copilot still requires a human to triage every alert it touches; it just makes the triage marginally faster. The organizations seeing double-digit reductions in MTTR and analyst toil are the ones that have moved at least one class of operational work past the copilot boundary into genuine agentic execution — systems where the AI plans a sequence of actions, executes them against real systems through governed tooling, and verifies the result before closing the loop, with humans supervising the exceptions rather than the routine.

This is not an argument against copilots. It's an argument for sequencing. Every organization we've worked with that jumped straight from copilot pilots to "let the agent do it" without an explicit maturity path either stalled on risk-committee objections or shipped an incident. The maturity model below exists because autonomy is not a single switch you flip — it's a series of deliberate, auditable steps, each with its own risk profile, its own guardrail requirements, and its own ROI case that a board can actually evaluate.

A five-level maturity model for operations AI

Borrowing the discipline of automotive autonomy grading but adapting it for the realities of IT and security operations, we define five levels. Each level is distinguished not by the sophistication of the underlying model but by three concrete, auditable properties: who plans the action, who executes it, and who verifies the outcome.

• Level 0 — Manual with search: humans plan, act, and verify. AI's only role is retrieval — search, dashboards, knowledge bases.
• Level 1 — Copilot / assistive: AI drafts a plan or a recommendation; a human decides whether to act, executes manually, and verifies manually.
• Level 2 — Supervised automation: AI plans and executes a narrow, pre-approved action through governed tooling, but a human must approve before execution (human-in-the-loop) and the AI reports the outcome for human verification.
• Level 3 — Conditional autonomy: AI plans, executes, and verifies its own work within a bounded domain and a defined blast radius, without per-action human approval; humans review by exception and receive full audit trails. This is the level where the plan-act-verify loop becomes a closed loop owned by the machine.
• Level 4 — Managed autonomy across domains: multiple specialized agents operate autonomously across IT, security, and identity domains, coordinating with each other, escalating cross-domain conflicts to humans, and continuously tuning their own guardrails based on outcome data.
• Level 5 — Autonomous operations with governance-as-code: agents own end-to-end operational domains against board-approved risk budgets, policy changes are themselves proposed and simulated by AI before human ratification, and the operating model resembles a governed fleet of digital operators more than a ticketing queue.

Very few organizations are at Level 4 today in any domain, and Level 5 remains aspirational for all but the most automation-mature hyperscale environments. That's not a criticism — it's a planning fact. The useful work for most enterprises in 2026 is moving specific, well-bounded workflows from Level 1 to Level 3, and doing it in a way that builds the evidence base needed to justify Level 4 later. Trying to leapfrog straight to broad autonomy is the single most common cause of failed agentic AI programs we see, because the guardrail and verification infrastructure required at Level 3 doesn't exist yet, and without it, Level 4 autonomy is just Level 1 risk with better marketing.

The plan-act-verify loop: what actually changes at Level 3

The jump from Level 2 to Level 3 is the hardest one in the model and the one that matters most, because it's the point at which the AI stops being a very fast typist for a human and starts being an accountable operator of a control loop. Understanding that loop mechanically is essential before any leader signs off on removing a human approval gate.

Plan

Planning is where an agent decomposes a goal — "remediate this critical CVE across the exposed asset population" or "contain this endpoint without disrupting the finance department's month-end close" — into a sequence of discrete, tool-callable steps. Modern agent architectures do this through a reasoning model that has been given a constrained action space (a defined toolset, not free-form shell access) and a current state snapshot (asset inventory, current alert context, prior remediation history, business criticality tags). The plan is not a black box: mature implementations require the agent to emit a structured, human-readable plan — the specific API calls, the order of operations, the expected state change, and the rollback step for each action — before any execution begins. This plan becomes the first artifact in the audit trail.

Planning quality is where most of the differentiation between vendors actually lives, and it's rarely about the underlying LLM. It's about how well the planning layer is grounded in real-time operational state: an agent that plans a firewall rule change without knowing that the target segment is mid-maintenance-window, or that plans a patch rollout without checking a known-bad-driver exclusion list, will produce technically fluent but operationally wrong plans. This is why context engineering — the pipelines that feed CMDB state, identity graphs, asset criticality, and business calendars into the planning step — matters more to reliability than model choice.

Act

Execution must happen through governed tool calls, never through generated scripts run with standing privilege. This is a non-negotiable architectural boundary. The agent should never have a shell; it should have a finite, versioned set of typed actions — isolateEndpoint, revokeSession, rollbackDeployment, quarantineFile, disableUser — each implemented as an idempotent, permission-scoped API with its own rate limits, blast-radius caps, and pre-conditions. The distinction between "an agent that writes and runs arbitrary remediation code" and "an agent that calls a constrained library of pre-vetted, pre-tested actions" is the single biggest predictor of whether a security or platform leader will approve autonomous execution. The former is a red-team's dream. The latter is auditable, testable, and revocable exactly like any other production API.

Verify

Verification is the step copilots skip entirely and the step that makes Level 3 fundamentally different from scripted automation. After executing an action, the agent must independently confirm the intended state change actually occurred and produced the desired effect — not just that the API call returned a 200. Did the CPU utilization actually drop after the process was killed? Did the endpoint actually disappear from the C2 beacon list after isolation? Did the failed login rate for the affected identity actually return to baseline after the credential was rotated? This closes the loop: verification failure triggers either an automatic rollback (for reversible actions within the agent's authority) or an escalation to a human with full context (for anything ambiguous or irreversible). Static, one-shot automation — the runbooks and scripts most organizations already have — executes and stops. Agentic automation executes, observes, and adapts.

This loop is exactly what platforms like an AI-native operations stack are built to run continuously rather than on-demand. In practice, we see this loop operating today inside alert triage and enrichment workflows — see AI-driven XDR alert triage — where an agent plans an investigation across multiple telemetry sources, pulls and correlates the evidence, and verifies whether the resulting classification is stable before it ever reaches an analyst's queue.

Architecture of an agentic operations platform

Underneath the maturity model sits a concrete technical architecture, and leaders evaluating vendors or build-vs-buy decisions should be able to name each layer and ask pointed questions about it. Six layers recur across every credible agentic operations implementation we've examined.

Telemetry and context fabric. Agents are only as good as the state they perceive. This layer normalizes logs, metrics, traces, EDR/XDR events, identity signals, CMDB records, and business context (change calendars, criticality tags, ownership) into a queryable, low-latency substrate. Without this, planning is guesswork dressed in confident language.

Reasoning and planning layer. The orchestration logic that turns a goal into a step sequence, typically a mix of a large language model for decomposition and a deterministic policy engine for constraint-checking. The policy engine matters as much as the model: it's what refuses to let the LLM plan an action outside the agent's authorized scope, regardless of how the model was prompted.

Tool and action registry. The finite, versioned catalog of governed actions available to agents, each with declared pre-conditions, blast-radius limits, required approval tier, and rollback procedure. This registry is the actual attack surface of your autonomous system, and it should be treated with the same change-control rigor as a production API gateway — because that's what it is.

Execution and sandboxing layer. Where actions actually run, with environment isolation, rate limiting, and circuit breakers that can halt an agent mid-sequence if anomalous behavior is detected (for example, an agent attempting an unusually high volume of isolation actions in a short window — a classic runaway-automation signature).

Verification and observability layer. Independent of the execution layer, this monitors actual system state before and after every action, maintains the immutable audit trail, and feeds outcome data back into both the planning layer (for continuous tuning) and human dashboards (for oversight).

Governance and policy layer. The human-authored constraints — risk tolerance by asset class, approval tiers, blackout windows, regulatory constraints, segregation-of-duties rules — that bound everything below it. This layer is where CISOs and compliance officers should spend their review time, because it's where organizational risk appetite becomes machine-enforced policy rather than a slide in a deck.

This layered separation is deliberate and it maps closely to how platforms like ITMox and CyberMox are architected: a shared context and reasoning substrate under domain-specific agents, so that an identity-focused agent operating through identity security and PAM workflows and an exposure-management agent operating through continuous threat exposure management both draw from the same verified asset and identity graph rather than maintaining divergent, drift-prone views of the environment.

Guardrails that make autonomy defensible

Every risk committee conversation about autonomous agents eventually converges on the same question: what stops this from going wrong at machine speed. The honest answer is a specific, layered set of guardrails, not a single "human in the loop" checkbox. Leaders should expect and demand all of the following before approving Level 3 autonomy for any workflow.

Scoped authority, not standing privilege

Agents should hold the minimum privilege required for their declared action set, provisioned just-in-time and revoked immediately after use, exactly as you would scope a service account — never a persistent admin credential sitting in a config file. This is where agentic operations and modern identity and privileged access management converge: an agent's identity should be as tightly governed, monitored, and rotated as your most sensitive human privileged account, arguably more so, because it acts far more often and far faster than any human operator.

Blast-radius caps

Every governed action needs a declared maximum scope — isolate at most N endpoints per hour, patch at most one canary group before requiring confirmation, disable at most one non-privileged account without escalation. These caps are what turn a bad plan into a contained incident instead of a cascading outage. They should be set conservatively at first and loosened only against evidence, not vendor assurance.

Reversibility tiering

Classify every action by reversibility: fully reversible (restart a service), reversible with cost (roll back a deployment, incurring some downtime), and irreversible (delete data, terminate a cloud instance, notify a regulator). Only fully and cheaply-reversible actions should ever run at Level 3 without a human approval gate in the first six to twelve months of a program. Irreversible actions stay at Level 2 — agent plans, human approves — far longer than most vendors will tell you, and that's the correct, defensible posture.

Explainable plans and immutable audit

Every plan, every action, every verification result must be logged in a form a non-engineer auditor can read, not buried in model chain-of-thought. Regulators and cyber-insurers are increasingly asking not just "was there a human in the loop" but "can you produce the decision trail for this specific autonomous action taken on this specific date." If your platform can't produce that trail in an afternoon, it isn't ready for Level 3 in a regulated environment.

Circuit breakers and anomaly detection on the agent itself

The agent's own behavior should be monitored the way you monitor any privileged actor: unusual action velocity, actions outside historical patterns, or a spike in verification failures should trip an automatic pause, not just log a warning. This is the guardrail most programs forget, because it requires treating the agent as a monitored entity in its own right rather than assuming good behavior because "it's AI."

Segregation of duties for AI

The agent that plans a remediation should not be the same instance that approves its own escalation threshold, and the agent that executes actions should be architecturally separate from the agent that verifies them, mirroring the separation-of-duties principle auditors already apply to human operators. This is exactly the discipline that underpins how a mature agentic SOC is designed: triage, response, and verification are distinct agent roles with distinct authority, not one monolithic "security AI" with god-mode access.

Mapping IT and security domains to maturity levels

Autonomy maturity is not a single organization-wide dial. It should be assessed and advanced workflow by workflow, because the risk profile of automatically restarting a stuck batch job bears no resemblance to the risk profile of automatically disabling a privileged identity. The table below reflects where we typically see well-run programs targeting each domain today, and it's a useful worksheet for a portfolio review: plot every candidate workflow against it before committing engineering time.

Notice the pattern: reversible, high-volume, well-understood actions (alert triage, endpoint isolation, cloud misconfiguration fixes) move to Level 3 fastest, because verification is cheap and rollback is fast. Actions touching privileged identity or regulatory attestation stay deliberately slower, not because the technology can't do it, but because the cost of a wrong autonomous action is asymmetric — a false-positive account disablement during a board meeting is a very different incident than a false-positive alert auto-close. Data-platform workflows, which increasingly sit underneath both IT and security operations through a unified foundation like MoxDB, deserve a special note: verification here means confirming lineage and schema integrity, not just process exit codes, because a "successful" pipeline repair that silently corrupts downstream data is worse than the outage it was meant to fix.

Metrics that satisfy a board, not just an ops team

Operations teams love MTTR and alert-to-close time, and those remain necessary. But a board and an audit committee will ask a different set of questions, and a maturity program should instrument for both audiences from day one rather than retrofitting governance metrics after a program has already scaled.

• Autonomous action volume and mix — how many actions were taken at each maturity level this period, broken out by domain, so leadership can see the autonomy footprint growing (or not) against plan.
• Verification pass rate — the percentage of autonomous actions whose post-action state check confirmed success on the first attempt. A declining trend is an early warning that context quality or planning logic has drifted before it ever produces a customer-facing incident.
• Rollback and escalation rate — how often autonomous actions required rollback or human escalation, tracked as a leading indicator, not a failure metric to be hidden. A healthy Level 3 program has a nonzero, closely watched rollback rate; a zero rate usually means the guardrails are too conservative to matter, not that the agent is perfect.
• Mean time to autonomous containment (MTTAC) — the security-operations analogue of MTTR, measured from detection to verified containment without human execution latency, which is where the ROI case against dwell time actually lives.
• Human review load — the count and duration of human-in-the-loop reviews per week, which should fall as workflows graduate levels; if it's flat while autonomous action volume rises, the exception-handling design is wrong.
• Cost per resolved action — fully loaded, including model inference, platform, and remaining human oversight cost, benchmarked against the fully manual baseline it replaced. This is the number finance will ask for, and it should be tracked per domain, not blended.
• Audit trail completeness — the percentage of autonomous actions with a complete, retrievable plan-act-verify record, which should be effectively 100% at any level above Level 1; anything less is a governance gap, not a rounding error.
• Guardrail trip rate — how often circuit breakers, blast-radius caps, or anomaly detectors intervened, which tells the board the safety system is alive and load-bearing rather than decorative.

The ROI narrative that resonates in the boardroom is rarely "we saved X analyst hours." It's the combination of a shrinking dwell time or downtime curve alongside a stable or improving verification pass rate — proof that speed was gained without a corresponding increase in error rate. Present those two curves together, every quarter, and the autonomy investment defends itself. Present speed alone, and you'll get exactly the skeptical follow-up question you should expect: how do you know it's actually right.

Operating model and organizational change

Technology is rarely the reason agentic operations programs stall past Level 2. The operating model is. Three structural changes recur across the programs that successfully reach Level 3 and beyond, and they are organizational decisions, not procurement decisions.

From tier-1 triage to exception management

As routine triage and remediation move to agents, the role of a tier-1 analyst has to be redesigned deliberately, not left to attrition. The winning pattern converts tier-1 headcount into an exception-management function: reviewing the plans agents flag as ambiguous, tuning the guardrails that generated too many false escalations, and handling the genuinely novel incidents agents correctly decline to act on. Organizations that try to simply shrink the tier-1 team without redefining its function lose the institutional knowledge that made the agents trustworthy in the first place, because that knowledge lived in the analysts who trained and corrected the system.

A cross-functional AI risk council, not a single owner

Because agentic actions cross IT, security, identity, and sometimes data-governance boundaries, no single team should own the guardrail policy layer alone. The programs that scale cleanly stand up a small, standing council — typically drawn from security engineering, IT operations, compliance, and a business risk owner — that approves any change to blast-radius caps, reversibility tiers, or autonomy-level graduation for a workflow. This council does for AI guardrail policy what a change-advisory board already does for production changes, and it should meet on a cadence measured in weeks, not quarters, because agent behavior data accumulates fast.

Graduation criteria, written down before the pilot starts

Every workflow moving from Level 2 to Level 3 should have explicit, pre-agreed graduation criteria: a minimum number of successfully verified actions, a maximum acceptable rollback rate over a trailing window, and a defined observation period with a named executive sign-off. Writing these criteria after the pilot is running invites both premature graduation under delivery pressure and permanent pilot purgatory under risk aversion. Writing them first turns a political decision into a data decision.

This operating-model discipline is exactly what distinguishes a mature integrated NOC-SOC function from two teams that happen to share a floor. When network operations and security operations run on a shared context fabric and a shared guardrail council, an agent handling a performance degradation and an agent handling a suspicious lateral-movement alert on the same host can actually coordinate — escalating to each other before escalating to a human — instead of each optimizing its own domain and colliding.

Build, buy, and vendor evaluation criteria

Most enterprises will not build a full six-layer agentic operations stack from scratch, and shouldn't try to for the same reason most stopped building their own SIEM correlation engines: the context fabric and verification tooling required to do it safely are a substantial, ongoing engineering investment that isn't your core business. But "buy" doesn't mean abdicating architectural judgment. When evaluating a platform vendor, press on specifics the maturity model surfaces directly, not on marketing claims about "AI-powered" anything.

• Ask for the tool and action registry, not a feature list. A vendor that can't show you the finite set of governed actions an agent can take, with declared blast-radius limits, is describing a chatbot with a script generator, not an agentic platform.
• Ask how verification is implemented for three specific action types you care about, and demand the mechanism, not the outcome. "We check the state changed" is not an answer; "we query the EDR API for beacon activity within 90 seconds post-isolation and compare against a five-minute pre-action baseline" is.
• Ask what happens when the model is wrong. A credible vendor has a rollback story, a circuit-breaker story, and an audit-trail story ready without hesitation, because they've had to answer this question from every serious prospect's risk committee.
• Ask how the platform's context fabric is kept current, and how staleness is detected. Planning against a six-hour-old asset inventory during an active incident is a guaranteed source of bad autonomous decisions.
• Ask whether the platform supports your deployment reality — cloud, on-prem, or air-gapped — without silently degrading verification quality in disconnected or sovereign environments. This is a genuine differentiator: many agentic platforms assume constant connectivity to a cloud model endpoint, which is a nonstarter for regulated or classified environments that require autonomy to function fully within an air-gapped boundary.

This last point deserves emphasis for CISOs operating in defense, critical infrastructure, or sovereign-cloud contexts: the guardrail and verification architecture described above has to run entirely within the trust boundary, including the reasoning layer, not just the dashboards. A platform whose planning step phones out to an external model endpoint cannot honestly claim to support an air-gapped deployment, no matter what the deployment diagram in the sales deck shows.

A worked example: ransomware containment across the maturity levels

Abstractions are easier to evaluate against a concrete scenario. Consider a mid-sized enterprise detecting early-stage ransomware behavior — anomalous mass file encryption activity on a file server, flagged by EDR telemetry at 2:14 a.m.

At Level 1, a copilot summarizes the alert, cross-references the process hash against threat intelligence, and drafts a recommended containment runbook. It pages the on-call analyst, who reads the summary, logs into the EDR console, and manually isolates the host. Elapsed time to containment: 25–40 minutes, dominated by human wake-up, orientation, and manual execution — not by analysis time, which the copilot has already compressed.

At Level 2, the agent has already built the full containment plan — isolate host, revoke active sessions, disable the associated service account, snapshot the volume for forensics — and pushes a single approve/deny decision to the on-call analyst's phone with the plan and its evidence attached. The analyst approves with one tap. Elapsed time: 8–12 minutes, dominated by notification latency and human confirmation, not analysis or planning.

At Level 3, within a pre-approved blast-radius (non-domain-controller, non-production-database hosts, business hours excluded from auto-action on finance-tagged assets), the agent executes the containment plan immediately upon detection, then runs its verification step: confirming the encryption process has terminated, confirming no further file-modification events originate from the host, and confirming the revoked session hasn't re-established. If verification passes, it closes the loop, generates the audit record, and notifies the security team asynchronously with the full evidence trail for morning review. If verification fails — encryption activity continues from a second process — it automatically escalates to a human with the failed state clearly flagged, rather than reporting false success. Elapsed time to verified containment: under 90 seconds from detection.

The difference between 25 minutes and 90 seconds against an active ransomware encryption process is not a marginal efficiency gain — at typical enterprise file-server encryption rates, it is frequently the difference between a contained incident affecting a handful of files and a multi-terabyte, multi-day recovery event. This is precisely the case for advancing well-scoped, reversible security workflows to Level 3 deliberately rather than leaving high-value containment actions stuck behind a human approval gate indefinitely out of general risk aversion. It's also why this specific pattern — bounded, verifiable, reversible containment — is typically the first workflow we recommend organizations graduate to Level 3, ahead of higher-stakes but lower-frequency actions like identity deprovisioning or production database changes.

Common failure modes and how to avoid them

Programs fail predictably. Recognizing the pattern early is cheaper than recovering from it after a board has lost confidence in the initiative.

Skipping verification to hit a demo date. The single most common failure is a program that ships Level 3 "autonomy" that actually only implements plan and act, with verification bolted on as a dashboard chart reviewed the next morning rather than a blocking step in the loop. This is Level 2 automation wearing Level 3 marketing, and it fails exactly when it matters most — during an incident where the first action didn't fully work and nothing caught it in time to prevent escalation.

Unscoped tool access. Giving an agent a general-purpose scripting capability "for flexibility" instead of a finite governed action registry feels efficient in a proof-of-concept and becomes the first finding in every subsequent security review. It also makes the audit trail effectively meaningless, because "the agent ran a script" tells an auditor nothing about what the script actually did.

Graduating on vendor confidence instead of your own outcome data. A vendor's published accuracy benchmark was measured against their test environment, not yours. Every workflow's graduation from Level 2 to Level 3 should be gated on your own trailing verification pass rate and rollback rate, observed in your environment, for a meaningful sample size — not a case study from a different customer with different asset criticality and different risk tolerance.

Treating the guardrail layer as a one-time configuration. Blast-radius caps and reversibility tiers set at program launch should be revisited on a fixed cadence as the environment changes — new asset classes, new regulatory obligations, new business-critical systems. A guardrail that was conservative and correct a year ago can silently become either too loose (as the agent's action set has quietly expanded) or too tight (blocking value the organization has since proven it can trust).

No plan for model or vendor change. As underlying models and platforms evolve, a program needs a re-validation process before a model swap goes live in a Level 3 workflow, exactly as you would re-test before a major dependency upgrade in production software. Treating a model update as a transparent, no-action-required background change is how a previously reliable agent starts producing subtly different plans that erode a verification pass rate no one is watching closely enough to notice in time.

Frequently asked questions