9

“Autonomous” turned up on a lot of technology vendors’ feature lists this year, and storage was no exception. It’s not hard to see why. AI has pushed infrastructure teams into territory their tools were never built for: more data, more workloads, more urgency, and nowhere near enough people to run it all by hand. “Autonomous” has become shorthand for “we solved that.”

But the word carries a myth worth dismantling up front, and it’s the one this piece is named for: the assumption that keeping a human “in the loop” means a person approves every action in real time. 

Hold those two ideas together — autonomous, yet a human signs off on everything — and they cancel out. Either the system waits on a person and isn’t autonomous, or it acts on its own and the human isn’t really in control. That apparent contradiction is why “human-in-the-loop” gets waved off as a marketing nicety.

The resolution is to see the model as two layers, not one sequence. The first is a standing policy: humans define the authorization boundaries ahead of time and own them. The second is the runtime loop, and it moves fast: an insight surfaces, the platform checks it against that standing policy, and executes automatically when the action falls inside the boundary, escalating to a person when it doesn’t or when the stakes are high enough that a human should still decide in the moment. Control stays with people. What changes is when they exercise it: they move to the policy layer, where the real decisions live. 

This distinction matters because “autonomous” means something different from one vendor to the next. One flags a problem and waits for a person; another just acts, no approval required. Buyers are left guessing which one they’re actually buying, and the guessing gets expensive when the data runs to exabytes and a mistake doesn’t stay small.

Here’s the definition of “autonomous” you should hold your vendor to: Humans set the policy up front; an AI agent surfaces a recommendation; the platform checks it against that policy and executes, at machine speed, only what’s already sanctioned, logging every step, and asking a person for anything the policy doesn’t cover.

Autonomous doesn’t remove the human; it moves the human earlier

Nobody responsible for an exabyte of production data wants a system that acts outside the boundaries they set, and nobody wants to sign an audit finding that reads “the platform decided.” 

So when a vendor’s language implies your operators are now optional, ask the direct question: What is this platform doing to our data when nobody’s watching, and can it prove it afterward?

This is where the myth does its damage. Because “human-in-the-loop” gets equated with real-time approval, teams conclude they must choose between staying in control and moving at machine speed, and vendors selling unbounded automation are happy to let them believe it. But the human’s real job is a different one: to decide, ahead of time, which actions are sanctioned and under what conditions, and to own that policy. The human authors the policy; the platform executes inside it.

Much of what’s marketed as autonomous storage is ordinary automation, or unbounded automation, dressed in self-driving language. Terms like self-healing, self-optimizing, zero-touch, and “the AI handles it” skip the only questions that matter: Which actions can the system take on its own, who decided that, and what happens to everything the policy doesn’t cover? 

Removing the human was never the goal. Removing the alert triage, the dashboard archaeology, and the 3 a.m. guesswork was the goal, and none of that should end with explaining to a regulator why your storage platform deleted something on its own.

Doesn’t a human in the loop just recreate the bottleneck?

Look at the clock an adversary is running. Average breakout time, from initial access to malicious activity, fell to 29 minutes in 2025 — 65% faster than the year before, with the fastest on record at 27 seconds (CrowdStrike 2026 Global Threat Report). At 27 seconds, no workflow that waits for a human decision in the moment wins that race. 

That’s exactly why the decision has to be made before the race starts. Any autonomous model whose answer to urgency is “page someone and hope they’re awake” isn’t a serious design.

That doesn’t mean storage should try to detect attacks at adversary speed. That’s not a storage-platform claim, and any vendor selling you one is back to autonomous-washing. In an agentic workflow, the relevant question is whether the action has already been authorized by policy before the moment of urgency. 

So, does a human in the loop create a new bottleneck? Only if you assume the human has to approve in real time. Pre-authorization changes that assumption: You decide in advance which actions are already sanctioned, starting with the reversible work, while anything that destroys data or capacity still requires a human decision in the moment, at least until the reversal itself has been tested and proven safe. And where no policy covers the situation, the workflow falls back to asking a person. That fallback is deliberate; at exabyte scale, it’s the only safe default.

Where the authorization boundary lives: Scality ADI (Autonomous Data Infrastructure) supports both models. Guardian, its built-in AI operations capability, is read-only: it recommends actions, and every action initiated through Guardian requires human approval. Customers operating ADI through their own agentic harness via  MCP can instead define authorization policies in that harness, allowing actions already sanctioned by those policies to execute without a new human decision in the moment. 

In the customer-operated model, that separation of duties shifts outside Guardian: the harness owns the authorization boundary, and the AI stack can invoke the operational actions exposed through MCP under the permissions assigned to it. 

That’s not something to downplay: The credential you hand your AI stack is privileged access, and it should be treated like one, with written policy, defined scope, and a record.

It’s worth being precise about what a “recommendation” is, too, because treating one as a glorified alert is a mistake:

• An alert asks for your attention.
• A recommendation asks for your decision.
• A decision carries liability.

That’s the trap in bounded autonomy: a long list of recommendations waiting on real-time approval becomes approval fatigue, and approvals turn into a rubber stamp instead of a check. Deciding in advance which actions your policy sanctions, and which it never will, is what makes autonomy safe to turn on in the first place.

The real product is the boundary, not the intelligence

Good recommendations are getting easy, so that’s no longer where the interesting engineering is. The hard part is the boundary: a policy layer the customer owns, enforced by the platform, with a record of what was proposed, who authorized it, what executed, and what changed.

In Scality ADI, policies are defined and approved by operators, not by opaque automation, and the customer keeps the audit trail. That ownership matters because at exabyte scale, a bad decision doesn’t stay small. 

ADI presents four tiers on a single S3 namespace:

• GPU-Direct (TLC flash, S3 over RDMA)
• Hot (QLC and NL-SSD)
• Warm (NL-SSD and HDD)
• Cold (tape and cloud)

At exabyte scale, an incorrectly authorized operation can affect an enormous amount of data before a human has time to intervene. That’s why, here more than anywhere, the boundary and the record have to hold.

The threat environment is exactly why the record matters as much as the boundary. In ransomware incidents, 34% of backup repositories were modified or deleted (Veeam 2025 Ransomware Trends). 

If you can’t establish whether an action was authorized, you’ve created an investigation problem at the worst possible moment. Teams have to reconstruct what happened, determine whether the activity was legitimate, and rebuild an auditable chain of accountability. Until you can rule it out, you’re working an incident. 

Object versioning tells you what changed; only the record tells you who sanctioned it. In Scality ADI, operator actions in the Supervisor and its API are written to logs you can forward to your own SIEM. And a record is only as good as the accountability behind it, so ask what any vendor is contractually on the hook for, not just what its architecture allows. 

A checklist for anyone selling you “autonomous”

Autonomy you can’t audit is an unbounded liability with better marketing. Don’t trust it. 

These questions are designed to expose the boundaries, controls, and accountability behind any autonomous claim.

Ask in the first meeting:

• What can it do without asking me? If the vendor can’t enumerate those actions, there’s no boundary.
• Can you produce the log, and can I prove it wasn’t altered? Ask about tamper evidence, retention, export into your own tools, and what the vendor is contractually liable for if the record is wrong. A record only the vendor can produce is their word on their letterhead.
• Whose policy governs it, and how finely can it be scoped? If the answer is “our defaults,” the policy isn’t yours, and neither is the risk. Scope it by action, tier, bucket, rate, share of capacity. Coarse scope is just a wider blast radius.

Take these to the architecture review:

• How is the recommender prevented from executing? If the same component can propose and act, they should say so. If not, ask whether read-only is enforced by a separate credential and API surface, or just asserted in configuration. Design intent is not a control.
• Can I watch it before I trust it? Ask for a dry run or a proposed-changes view. Autonomy you can’t rehearse is autonomy you’re testing in production.
• Can an approved action be undone? Ask what rollback exists, at what granularity, within what window. “Restore from backup” is not an undo.
• What happens when the loop breaks? If the approving stack is unreachable or policy evaluation fails, does the platform stop, queue, or proceed on its last instruction? Fail-open is a decision someone made for you. And how do you halt it mid-action: an immediate stop or credential revoke, and who’s allowed to pull it?
• Who is accountable when the policy was wrong? The answer should identify a clearly accountable owner, not end with “the system decided.”

Put this list of questions to your incumbent and every challenger you’re evaluating, and compare the answers side by side. Ask Scality the same questions. If we can’t answer them, we haven’t earned the word “autonomous” either. 

Some of our answers are already on the record. At AI Field Day 8, we demonstrated Guardian and the MCP operational plane in front of independent delegates who were there specifically to push back and ask the hard questions.

Policy first. Then insight, check, execute.

“Autonomous” will keep showing up in storage marketing. The word itself proves nothing; what matters is whether a vendor can show you a human-authored policy set ahead of time, then insight, a policy check, and execution, with a record to prove it. Anything less is a guess dressed up as a feature.

Here’s what earning it looks like: Autonomous storage still involves you, earlier than you’d expect. You set the boundaries in policy up front; an agent surfaces what’s happening; and the platform executes, at machine speed, only what those rules already sanction, logging every step and asking a person whenever the rules don’t cover the call.