Blog
7.29.26

Prioritization is dead. Auto remediation is what replaces it.

Damiano Bolzoni
Co-founder & CTO

I have spent the last year focused on solving the problem of the prioritization approach. Not because ranking vulnerabilities is a bad idea. Because ranking was never the job. The job was always to close the risk. Prioritization just told you where to focus while the backlog grew.  

Today we are announcing the part of Kai that actually closes it: Auto Remediation, developed based on requirements of some of the largest Enterprises in the world.  

What changes today

Every finding that reaches Kai gets a binary decision. Not a score. Not a queue position. A decision based on deep context. Is this a real risk? If it is, can Kai fix it without a human in the loop, or does it need one?

For the vast majority of findings that represent confirmed risk, a fix exists and can be deployed, and Kai applies it. No meeting, no waiting on a Slack thread that goes quiet for three weeks. We call this track Kai Auto-Remediated.

For the complex few, the ones that Kai recommends a human review, 99% of the work is putting the plan together, and that is the part Kai executes. Because of the criticality of the application, Kai recommends a human review the plan before remediation begins. Kai builds the full remediation plan, stages the change, identifies the right owner, and opens the ticket with everything the technical team needs to act in minutes instead of days or weeks. We call this track Kai-Assisted.

Kai Watch covers the gap while the fix lands

Auto remediation handles the vast majority of findings the moment they are confirmed. But the complex few, where a patch might need a maintenance window, or an owner might need a day to review a plan, cannot close instantly. That gap, between confirming a risk is real and actually closing it, is exactly where attackers operate. Customers have told us that deploying mitigating controls is practically possible only in a handful of cases. So, we built Kai Watch to work with existing tools to enforce rules and monitoring without slowing down operations.

Kai Watch generates and deploys context-based detection rules the moment an exposure is confirmed, then continuously monitors SIEM, EDR, and XDR telemetry for signs of active exploitation.  It is scoped specifically to the risk still waiting for a human to resolve, so the moment something tries to touch it, the team knows. It is what makes it safe to let those fixes take the time they need instead of forcing a rushed change into production. Risk gets contained the instant it is real, not the instant someone gets around to patching it.

Why this had to happen now

The data keeps proving why this had to happen now: the gap between how fast an exposure becomes exploitable and how fast a human-speed team can close it was already too wide. Prioritizing vulnerabilities doesn’t narrow the gap. Closing it is the only option, which means something has to execute the fix while something else watches the exposure, both operating at machine speed. That is Auto Remediation and Kai Watch, working together.

This is what autonomous defense and working across categories means. Kai functions end-to-end, across security, engineering, and IT at machine speed. Optimizing one cog in the machine is not sufficient to execute defense at the speed of offense. Every foundational workflow has to be rebuilt.

Prioritization kept the backlog alive. Kai eliminates it.

Prioritization is dead. Auto remediation is what replaces it.

Damiano Bolzoni
Co-founder & CTO
July 29, 2026

I have spent the last year focused on solving the problem of the prioritization approach. Not because ranking vulnerabilities is a bad idea. Because ranking was never the job. The job was always to close the risk. Prioritization just told you where to focus while the backlog grew.  

Today we are announcing the part of Kai that actually closes it: Auto Remediation, developed based on requirements of some of the largest Enterprises in the world.  

What changes today

Every finding that reaches Kai gets a binary decision. Not a score. Not a queue position. A decision based on deep context. Is this a real risk? If it is, can Kai fix it without a human in the loop, or does it need one?

For the vast majority of findings that represent confirmed risk, a fix exists and can be deployed, and Kai applies it. No meeting, no waiting on a Slack thread that goes quiet for three weeks. We call this track Kai Auto-Remediated.

For the complex few, the ones that Kai recommends a human review, 99% of the work is putting the plan together, and that is the part Kai executes. Because of the criticality of the application, Kai recommends a human review the plan before remediation begins. Kai builds the full remediation plan, stages the change, identifies the right owner, and opens the ticket with everything the technical team needs to act in minutes instead of days or weeks. We call this track Kai-Assisted.

Kai Watch covers the gap while the fix lands

Auto remediation handles the vast majority of findings the moment they are confirmed. But the complex few, where a patch might need a maintenance window, or an owner might need a day to review a plan, cannot close instantly. That gap, between confirming a risk is real and actually closing it, is exactly where attackers operate. Customers have told us that deploying mitigating controls is practically possible only in a handful of cases. So, we built Kai Watch to work with existing tools to enforce rules and monitoring without slowing down operations.

Kai Watch generates and deploys context-based detection rules the moment an exposure is confirmed, then continuously monitors SIEM, EDR, and XDR telemetry for signs of active exploitation.  It is scoped specifically to the risk still waiting for a human to resolve, so the moment something tries to touch it, the team knows. It is what makes it safe to let those fixes take the time they need instead of forcing a rushed change into production. Risk gets contained the instant it is real, not the instant someone gets around to patching it.

Why this had to happen now

The data keeps proving why this had to happen now: the gap between how fast an exposure becomes exploitable and how fast a human-speed team can close it was already too wide. Prioritizing vulnerabilities doesn’t narrow the gap. Closing it is the only option, which means something has to execute the fix while something else watches the exposure, both operating at machine speed. That is Auto Remediation and Kai Watch, working together.

This is what autonomous defense and working across categories means. Kai functions end-to-end, across security, engineering, and IT at machine speed. Optimizing one cog in the machine is not sufficient to execute defense at the speed of offense. Every foundational workflow has to be rebuilt.

Prioritization kept the backlog alive. Kai eliminates it.