Why SolarWinds built approval and audit into Avior, not around it

On 14 October 2026, SolarWinds announced Avior, a standalone agentic AI system built on the SolarWinds Platform for IT operations. It correlates alerts, runs root cause analysis, remediates configuration drift and manages asset lifecycle across hybrid estates, coordinating what the company calls specialised agents toward goals the operator sets (Help Net Security, 14 October 2026).

Every observability vendor is adding agents. What stands out at SolarWinds is what it built around them before shipping: risk-tiered autonomy that routes potentially dangerous actions to a human for explicit approval, granular audit trails that record every change, automated rollback, data masking and least-privilege tool access by default (Help Net Security, 14 October 2026). Cullen Childress, SolarWinds' interim CEO and chief product officer, framed the shift as one from "managing alerts to orchestrating outcomes." Steven Khan, an observability engineer at Radiology Partners quoted in the same piece, described Avior as "almost like having an additional teammate" for triage (Help Net Security, 14 October 2026).

A vendor whose product can restore configurations and touch production infrastructure built approval gates and an audit ledger into the architecture rather than offering them as an add-on. That is a design decision worth reading closely, because it is an admission about what happens when agents are left to run without one.

Why this is not an isolated choice

SolarWinds is responding to a problem that is already measured elsewhere, not inventing a hypothetical one. Reco's State of Agent Security 2026 (26 August 2026), built from enterprise telemetry and analysis of 500 public Model Context Protocol servers, found 80% of AI tools running with no oversight at all, and in smaller organisations 414 unsanctioned AI tools per 1,000 employees. Two years into agentic AI adoption, oversight has not caught up with deployment; it has fallen further behind as the tools multiply.

The identity layer behind those agents is weaker still. As Roy Katmor, co-founder and CEO of Orchid Security, has put it, agent deployments routinely leave "the agent approved, the studio approved, but the identities behind them sitting outside the usual review process." Permissions accumulate as integrations are added and scopes are copied between service accounts, until an agent holds authority well past its original job (Orchid Security).

Put the two together and a pattern emerges. Agents are being deployed with production level reach, inside organisations that cannot see what most of them are doing, built from identities that nobody formally reviewed. Avior's approval tiers and audit record are a vendor's answer to exactly that gap, applied to one category: IT operations agents that can touch live infrastructure.

What it means for a regulated enterprise

An IT operations agent that can restore a last known good configuration, rotate capacity, or retire an asset is not a monitoring tool. It is a system with write access to production, and write access to production is precisely what access reviews, change management controls and incident records exist to govern.

Under NIS2, cybersecurity risk management is a management level obligation with personal accountability attached, and an agent that can change infrastructure state without a recorded approval is the kind of gap that obligation is written to close. The EU AI Act's record keeping requirements assume an organisation can show what a system did and on whose authority; that assumption fails the moment the only record is "the agent handled it." ISO 27001 and SOC 2 change management controls expect an approver and a timestamp for anything touching production, regardless of whether a human or an agent initiated the change.

Any enterprise running agentic tooling against live infrastructure, in observability, ITSM, cloud cost management or elsewhere, inherits the same obligation, not only SolarWinds' customers: the agent's actions need an owner, an approval trail and a record that survives the audit, not just the incident.

What actually addresses it

What matters is the separation between an agent proposing a change and a human authorising it, paired with a record that is generated by the system doing the work rather than reconstructed afterwards from logs scattered across tools.

That separation has two necessary parts. First, risk tiering: not every action an agent can take carries the same blast radius, so the approval gate has to sit in front of the ones that do, rather than in front of everything or nothing. Second, an audit trail that is append only by construction, so the record of what was approved and what actually ran cannot be edited after the fact to match what should have happened.

This is the same requirement regulated enterprises already face for human change management, applied to a new class of actor. An agent that proposes a configuration rollback is, for governance purposes, no different from an engineer submitting a change ticket: both need an approver, both need a timestamp, and both need a record that a reviewer six months later can actually read.

What to check on Monday

Pick one agent in your estate that currently has write access to a production system, whatever vendor built it. Ask three questions: Does any action it can take require a human approval before it runs? If it made a change last week, can you produce the record of who or what approved it, with a timestamp, in under five minutes? And if you needed to revoke its access right now, how long would that actually take? If any answer is uncomfortable, that is the gap Avior's approval tiers and audit trails were built to close, and it is not specific to one vendor's agents.