Tamnoon CEO Marina Segal on the Self-Healing Cloud: Why It Starts With a Machine That Knows When Not to Act

Cloud security vendor Tamnoon on Tuesday launched a public Cloud Remediation Index and a running record of remediations its engine declined to execute, framing both as the groundwork for what CEO Marina Segal calls a self-healing cloud: an environment in which known exposures are closed through the customer's own change process, automatically, with a defensible record of how.

The company's dataset of 14.86 million detections across hundreds of enterprise environments shows the distance from that goal. Fifty-three percent of everything ever detected in the cloud remains open, up from 41% a year earlier. A critical finding now takes an average of 150 days to close, up from 128. CrowdStrike's 2026 Global Threat Report puts the average eCrime breakout time, from initial foothold to lateral movement, at 29 minutes.

"Your cloud already heals itself in one sense," Segal said. "But 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."

What Self-Healing Actually Means

Segal, who was part of the Dome9 Security team that defined cloud security posture management and stayed on at Check Point after the acquisition, draws a sharp line between resilience and healing. Container orchestrators restart failed pods. Auto-scaling replaces unhealthy instances. None of that closes an internet-exposed bucket, revokes an over-permissioned role, or shuts a port that should never have been open. Those findings are detected within minutes and then, in her words, filed.

"We built an industry that could see every problem in the cloud, and then we filed the problems," Segal said. Detection, she argues, is finished. Closure is where the decade ahead will be decided.

A self-healing cloud, as Tamnoon defines it, has four properties. Exposures close without a human designing each change. Changes go through the customer's existing change-management process, with rollback prepared. Every closure carries a record an auditor can read. And the machine doing the closing can tell when a fix is unsafe and decline it.

Why the Fourth Property Comes First

That last property is where Tamnoon, co-founded by Segal in 2021, diverges from the rest of the remediation category. Nearly every cloud security platform has shipped an auto-remediation agent in the past 18 months. According to Segal, most remain switched off in production, because a wrong automated change does not present as a security failure. It presents as an outage with a change ticket naming the person who approved it.

"Every vendor in this market is selling speed," Segal said. "Speed was never the problem. They were afraid it would be wrong, and that they would be the one who said yes to it."

Tamnoon's engine was therefore built to decide before it was built to act. Before modifying a resource it evaluates dependencies, ownership, recent changes and observed traffic, then takes one of three paths: execute the change through the customer's process with a rollback ready, decline it with a written justification, or escalate to a human when a required fact such as ownership is missing.

"A machine learns to act long before it learns when to stop," Segal said. "We taught ours in the other order. The first thing we automated was restraint. A machine that cannot say no is not automation. It's a liability with an API."

In a demonstration, six internet-exposed storage buckets that appear identical to a scanner produce three outcomes: three are closed, two are declined because the change would sever a live dependency the scanner cannot see, and one is escalated because the owner is unknown. One alert, three correct answers.

Healing That Stays Healed

Every decision, closure or refusal, produces a six-field record: the finding, what was read first, the verdict, the reason, the one fact that would change the verdict, and how to do it by hand. Customer overrides are logged and become part of how the engine judges that environment next time.

That record is what makes healing durable rather than cosmetic. In Tamnoon's dataset, the same eight misconfigurations account for a fifth of all alert volume and return quarter after quarter, closed by hand and reopened by the next change. An engine that closes them through the change process, with the dependency context recorded, and remembers the decision for that class of finding, closes them differently. What heals once stays healed.

Autonomy is granted per class of finding on evidence. The engine connects read-only and changes nothing in the customer's cloud by default. It earns write permission on a class only after its decision record on that class holds, and customers retain veto authority throughout. "You keep the veto," Segal said. "It earns the keys. And it can lose them. Autonomy isn't a feature you buy. It's a track record."

The engine ingests findings from 17 scanners, including Wiz and CrowdStrike Falcon Cloud Security, and its cross-scanner correlation resolves 142 alerts into one piece of work, on average. Tamnoon reports one customer reducing open findings from 6,074 to 2,041 over four quarters, with 93% fewer new alerts arriving by the end of the period, and a healthcare customer measuring a single remediation at $8,775 by hand versus $775 through the engine. Warner Music Group is a named customer. The company has raised more than $18 million, including a Series A led by Bright Pixel Capital.

Measuring How Slowly the Cloud Heals

Cloud security has always published how fast attackers move. It has been much quieter about how slowly it heals. The Cloud Remediation Index, out today, is built from the same 14.86 million detections behind the company's report and answers two questions in one place: what share of everything ever detected is still open, and how long a critical finding stays open. The attacker's clock is measured in minutes. This one is measured in months.

The companion refusals record lists remediations the engine declined, each with its six-field record.

"Every company in this industry publishes its wins," Segal said. "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."

Tamnoon has also published six questions for buyers to put to any remediation vendor, itself included. The first: can it refuse a change, and show one refusal with the evidence attached. "Everyone demos the fix," Segal said. "Ask them to demo the decline."

The Next Five Years

Segal's picture of the self-healing cloud is specific. Security teams stop being the liability boundary for changes they did not design. The backlog becomes a queue with verdicts in it rather than a filing cabinet. Engineers see one problem where they saw 142 alerts. The same misconfigurations stop returning. And autonomy is granted per finding class, like a credit limit, on evidence.

Her three predictions: refusal becomes a line in every remediation RFP, the decision record replaces the risk score as the comparison buyers make, and 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 said. Tamnoon puts it in two sentences: everyone automates the yes; we mastered the no.