The cloud security industry spent ten years perfecting detection. Scanners now spot misconfigured buckets, exposed ports and over-permissioned roles within minutes of creation. Yet more than half of everything ever detected remains open. A critical finding takes 150 days on average to remediate—and that number is worsening. Meanwhile, attackers move from initial access to lateral movement in 29 minutes. The gap between detection and healing has become the industry's defining problem.

Marina Segal watched this unfold from inside the industry. She helped build the detection machines at Dome9 Security, which defined cloud security posture management before Check Point acquired it. When she founded Tamnoon in 2021, she chose to solve a different problem than speed. "Nothing happened to them," she says of the detected findings. "We built an industry that could see every problem in the cloud, and then we filed the problems."

Why automation keeps the switches off

The industry's response to the remediation backlog was predictable: automation. Nearly every cloud security platform now ships an agent capable of making changes directly. Yet most customers leave these features disabled. The reason has little to do with technology and everything to do with accountability. In production environments, every change carries someone's name. Teams hesitate to approve changes they cannot fully explain, because a faulty remediation becomes an outage with a clear culprit.

Segal sees this caution as rational, not a training or culture problem. "Every vendor in this market is selling speed," she says. "Speed was never the problem. Nobody was ever afraid the fix would be slow. They were afraid it would be wrong, and that they would be the one who said yes to it." She frames the core issue bluntly: "A machine that cannot say no is not automation. It's a liability with an API."

Building restraint first

Tamnoon's architecture inverts the standard approach. Rather than building a system designed to act and then adding safeguards, Segal's team taught the engine to refuse first. "A machine learns to act long before it learns when to stop," she explains. "We taught ours in the other order. The first thing we automated was restraint. That order is the whole company."

A demonstration illustrates the difference. Six identical open storage buckets trigger the same alert with identical severity. The engine reads all six and produces three distinct answers: it closes three safely through the customer's own change process with rollback ready; it declines two in writing because closing them would sever live connections the scanner cannot see; it neither closes nor declines the sixth, instead asking for clarification because the owner is unknown. One alert. Three correct answers. The scanner was right every time, but the scanner was never the problem.

What transforms refusal from obstruction into utility is the evidence attached. A decline includes the finding, what was read first, the verdict, the reason, the single fact that would change the verdict, and steps to remediate manually. "A refusal without evidence is a shrug," Segal says. "A refusal with the evidence is a decision you can defend at nine in the morning. Declined is an answer."

Autonomy earned, not granted

The second departure from industry convention concerns trust. Vendors typically ship automation capabilities and let customers choose how much to enable. Tamnoon begins with the dial at zero. The engine connects read-only and makes no changes until it earns the right to act on specific finding classes. The customer retains veto power throughout. "You keep the veto," Segal says. "It earns the keys. And it can lose them. Autonomy isn't a feature you buy. It's a track record, and a track record is something you can read."

Every decision—closures and refusals alike—generates a receipt with six readable fields that auditors can understand without translation. When a customer's engineer overrides the engine, that override enters the record too, shaping how the engine behaves in that environment next time. The system learns from the entire fleet while becoming stricter about each customer's specific cloud. "The board will never ask you how fast the fix was," Segal says. "They will ask how you knew it was safe. We built the answer to the second question."

What healing actually means

Segal is deliberate about language when discussing self-healing clouds, knowing operations teams might envision restarting pods. "Your cloud already restarts itself," she says. "It has never once closed its own security hole. Healing means the exposure is gone, through your own change process, and someone can defend how."

Her five-year vision is concrete. Security teams stop serving as liability boundaries for changes they did not design. The remediation backlog transforms from a filing cabinet into a queue with verdicts. Engineers see one problem instead of 142 alerts—the ratio Tamnoon's cross-scanner model produces on average. Recurring misconfigurations stop returning quarterly because fixed issues stay fixed. Autonomy becomes something granted per finding class, like a credit limit, based on evidence.

She offers three predictions and welcomes being proven wrong publicly. Refusal becomes a line item in every remediation RFP. The receipt replaces the score as the metric buyers compare. No vendor sells remediation without demonstrating a decline. "In five years nobody will buy remediation from a vendor who can't show them what it refused," she says. "The question will sound obvious. Today nobody asks it."

Customers running the engine for a full year report striking changes in their metrics. One reduced open findings from 6,074 to 2,041 over four quarters—three times fewer—with 93% fewer new alerts by the end. A healthcare company calculated that closing a single finding cost $8,775 manually versus $775 through the engine. Warner Music Group is a named customer. Tamnoon has raised more than $18 million, with a Series A led by Bright Pixel Capital, and its engine reads findings from seventeen scanners including Wiz and CrowdStrike Falcon Cloud Security.

Publishing the declines

Today Tamnoon released two things the industry rarely publishes. The first is a number: the Cloud Remediation Index, derived from 14.86 million detections, showing what percentage of all detected issues remain open and how long critical findings stay unresolved. Attackers move in minutes. This metric is measured in months.

The second is a public record of remediations the engine declined, each with all six fields of evidence. "Every company in this industry publishes its wins," Segal says. "We are publishing the changes we did not make. It is a strange list to be proud of, until you ask which of the two lists a security team should read before it lets a machine into production."

The company also published six questions for any remediation vendor evaluation, starting with the first: can it refuse a change and show one refusal with attached evidence. "Everyone demos the fix," Segal says. "Ask them to demo the decline."

This is an unconventional relaunch for a security company—leading with what the product will not do and a metric the industry avoids discussing. But the conventional approach has had a decade, and half of everything it found remains unfixed. Segal's wager is that the second decade of cloud security belongs to machines that have earned the right to touch production, one refusal at a time. The company's own phrase for it is eight words: "Everyone automates the yes. We mastered the no."

Source: The Next Web