Cloud security spent a decade learning to see everything. Half of what it found is still open. Tamnoon’s CEO says the next decade belongs to machines that know when not to act, and as of today she is publishing what hers refused.
Marina Segal helped build the machines that see everything.
She was at Dome9 Security when it defined cloud security posture management, and at Check Point after it bought the company. The idea won completely. Today a misconfigured bucket, an open port or an over-permissioned role shows up in a console within minutes of being created, in any cloud, on any of a dozen scanners. Detection is finished. Nobody serious argues otherwise.
Then she watched what happened to the findings.
“Nothing,” she says. “Nothing happened to them. We built an industry that could see every problem in the cloud, and then we filed the problems.”
Her company’s own data puts a figure on the filing cabinet. More than half of everything ever detected in the cloud is still open. A critical finding now takes 150 days on average to heal, and the number is getting worse, not better. By CrowdStrike’s count, an attacker moves from first foothold to lateral movement in 29 minutes. The defender’s clock, once the alert has fired, runs in months.
Segal co-founded Tamnoon in 2021 to close that gap. What she built is stranger than a faster button. She built a machine whose proudest output is a refusal.
Everyone automated the yes
The industry’s answer to a remediation backlog was always going to be automation, and in the last eighteen months it arrived in force. Nearly every cloud security platform now ships an agent that offers to make the change itself. The launch posts promise the same things: speed, an approval step, a rollback, control.
Most of those switches stay off.
Ask a cloud security team why, and the answer has nothing to do with the technology. It has to do with the name on the change. In production, every change is somebody’s responsibility, and nobody approves a change a machine cannot explain. A wrong remediation does not look like a security failure. It looks like an outage, with a ticket that says who approved it.
“Every vendor in this market is selling speed,” Segal 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 thinks the fear is correct. Not a training problem, not a change-management problem, not a culture problem. A rational response to automation that has never once shown a buyer what it would refuse to do.
“A machine that cannot say no is not automation,” she says. “It’s a liability with an API.”
The first thing we automated was restraint
Here is where Tamnoon parts from the rest of the category, and it parts at the root.
Every remediation product is built to act. Tamnoon’s engine was built to decide, and the first decision it learned was no. Before it was allowed to change anything in a customer’s cloud, it was taught to read: what depends on this resource, who owns it, what changed recently, what the traffic says. Then it was taught to refuse the change it could not prove safe, and to say why.
“A machine learns to act long before it learns when to stop,” Segal says. “We taught ours in the other order. The first thing we automated was restraint. That order is the whole company.”
The demo Tamnoon runs makes the point in under a minute. Six storage buckets, open to the internet, identical in the scanner. Same alert, same severity, same red. The engine reads all six. Three are safe to close, and it closes them, through the customer’s own change process, with a rollback ready. Two it declines, in writing, because the change would have severed something live that the scanner could not see. One it neither closes nor declines. It asks, because the owner is unknown and it will not guess.
One alert. Three correct answers. The scanner was right every time. The scanner was never the problem.
What makes the refusal useful rather than annoying is what comes with it. A decline from the engine carries the finding, what was read first, the verdict, the reason, the one fact that would change the verdict, and the steps to do it by hand. “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 isn’t granted. It’s earned.
The second break with the category is about trust, and it inverts how the industry has sold automation for twenty years.
The convention is a dial. The vendor ships the capability, the customer chooses how much of it to switch on, and the risk of the choice belongs to the customer. Tamnoon’s engine starts with the dial at zero. It connects read-only and changes nothing in the customer’s cloud. It is granted the right to act on a class of finding only after its record on that class holds, and the customer keeps the veto 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.”
The unit of that record is the receipt. Every decision the engine makes, closures and refusals alike, becomes one: six fields, readable by an auditor without a translator. When a customer’s engineer overrides the engine, the override goes into the record too, and becomes how the engine judges that environment next time. It gets smarter from the whole fleet and stricter about each customer’s 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 a cloud that heals itself actually looks like
Segal is careful with the phrase, because operations people hear it and think of pods restarting.
“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 picture of the next five years is specific. Security teams stop being the liability boundary for changes they did not design. The backlog stops being a filing cabinet and becomes a queue with verdicts in it. Engineers see one problem where they used to see 142 alerts, which is the ratio Tamnoon’s cross-scanner model produces on average. The same eight misconfigurations stop coming back every quarter, because what heals once stays healed. And autonomy stops being a checkbox in a vendor’s settings and becomes something granted per class of finding, like a credit limit, on evidence.
Three predictions come with it, and she is willing to be wrong about them in public. Refusal becomes a line in every remediation RFP. The receipt replaces the score as the thing buyers compare. And no vendor sells remediation without showing 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.”
The customers who have run the engine for a full year describe the change in ratios. One went from 6,074 open findings to 2,041 over four quarters, three times fewer, with 93% fewer new alerts arriving by the end. One healthcare company priced a single finding end to end: $8,775 to close it by hand, $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, Wiz and CrowdStrike Falcon Cloud Security among them.
The number, and the record
Today Tamnoon publishes two things this market does not usually publish.
The first is a number. Cloud security has always published how fast attackers move. It has been much quieter about how slowly it heals. The Cloud Remediation Index, out this morning, comes from the same 14.86 million detections behind the company’s report, and it 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 second is a record. As of today, Tamnoon keeps a public page of the remediations its engine declined, each with the six fields.
“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.”
Alongside them, the company has published the six questions it says buyers should 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 says. “Ask them to demo the decline.”
It is an unusual way to relaunch a security company, leading with what the product will not do and a number the industry rarely publishes about itself. But the conventional way has had a decade, and half of everything it found is still open. Segal’s bet is that the second decade of cloud security belongs to the machine that has earned the right to touch production, one refusal at a time. The company’s own words for it are eight.
Everyone automates the yes. We mastered the no.