Opinion
Autonomous remediation won't arrive as a big red button
“Cloud security is moving from ranking alerts to proving exploitability and fixing verified risk on its own,” writes Shimon Tolts, co-founder and CEO of Copperhelm. “The way there is crawl, walk, run.”
A critical cloud-security alert lands in a queue. The scanner has found a vulnerable package, a risky permission or an exposed service. That finding is best treated as a hypothesis about risk. The team still has to establish whether the conditions for exploitation exist in this environment, who owns the system and what can be changed without breaking production.
Published severity is public. Exploitability is private. A vulnerable package may exist on disk without ever being loaded into memory. A medium-severity issue can become critical when it connects an exposed application to a privileged identity. The same finding can also change meaning over time as network controls, permissions and cloud resources change around it.
The industry has spent a decade getting better at finding and ranking these issues. The harder part has always come after the alert: proving which ones matter and fixing them. Automation and AI can test combinations of weaknesses, permissions and exposed paths at machine speed, while many defensive workflows still triage and fix findings one by one. Analysts verify whether a process is running, trace network reachability, inspect permissions, identify the owning team and decide which intervention is safe. Then someone opens a ticket and waits for a change window. In a large cloud environment, that sequence repeats across thousands of findings, and the backlog grows faster than any team can close it.
Closing it at machine speed means moving toward autonomous remediation: systems that do not just flag risk but act on it. But no one is ready for a big red button, a single switch that hands production to an agent on day one. Security leaders are right to be cautious. A wrong change in a live environment can cause an outage as damaging as the breach it was meant to prevent. Autonomy has to be earned the way trust is earned with a new engineer: gradually, with evidence and within clear limits.
Evidence before action
Collection, modeling, exposure mapping and filtering should remain deterministic wherever possible. Agents are most useful in the last mile, where the path through the evidence changes from case to case and a rigid workflow starts to break down.
One agent can examine what is running on a workload, another can map reachability and network controls, and another can test whether the conditions for exploitation are present. Their conclusions need evidence from the environment: command outputs, process information, network paths and the controls that actually sit between an attacker and the resource. When the evidence does not meet the policy threshold for action, the case should stop or escalate rather than guess.
Remediation may mean upgrading a vulnerable package or server. Mitigation may mean blocking the path to the vulnerable service while the underlying issue remains. A control can close one route while leaving another open. A WAF rule, for example, may block traffic through the expected path while a public IP or another network route still reaches the same server directly. Any system trusted to act has to understand that difference before it is allowed to act at all.
Crawl, walk, run
The practical way to reach autonomous remediation is to expand it in stages, per action and per environment, rather than all at once.
Crawl: instruct. The system investigates, prioritizes and hands the team clear remediation instructions: the finding, the evidence that it is exploitable, the owner, the fix and how to roll it back. Engineers execute. This alone removes most of the investigation work, and it lets the team compare the system's judgment with its own.
Walk: execute with approval. The system prepares the change and carries it out after explicit approval. Before anything runs, it shows what the action touches, what could be affected and how to undo it. The team stops writing changes and starts reviewing them.
Run: automate within guardrails. For actions the team has validated, the system acts on its own within predefined policies, thresholds and escalation rules. A security team might allow an agent to add a protective WAF rule in monitor mode, observe the effect and move to enforcement automatically when the evidence meets policy.
These stages are not a one-time migration. The same organization can run automatically on reversible, low-risk mitigations while staying in walk for production upgrades and sensitive permission changes, and in crawl for anything touching a critical database. Blast radius, reversibility and the organization's policy decide where each action sits. As outcomes build a track record, teams move more actions up a stage, at a pace they control.
Autonomy with boundaries
More capable models expand what can be automated, but evidence, permissions and action boundaries still govern what happens in a live environment. Copperhelm recently joined Anthropic's Cyber Verification Program, which gives vetted security practitioners access to select Claude models for legitimate defensive work under a different safeguards framework. An agent still needs to produce evidence, operate within defined permissions and act only where policy allows it.
Accepted risk has an expiration condition. A vulnerability may be acceptable because the affected service is not reachable or another control blocks the path. That decision remains valid only while those conditions hold. A changed load balancer, a new public IP or a removed network rule can alter the meaning of the same finding. In a changing cloud environment, that reassessment has to be event-driven: a change in exposure, routing or permissions should reopen the findings it affects, and send them back through the same crawl, walk or run path.
In Agentic Cloud Security, scanners and telemetry feed the process, deterministic checks reduce what needs reasoning, agents investigate the cases that remain, and policy decides which fixes the team executes, which it approves and which run on their own.
The practical benchmark for the next phase of cloud security is not how many alerts a system can rank, but how much verified risk it can close safely, and how quickly a team can trust it to close more.
Shimon Tolts is co-founder and CEO of Copperhelm.
