Nobody's Real Objection to Auto Remediation Is Auto Remediation

This is the second post in a series on the throughput gap. The first, by our CEO Galina Antova, laid out why remediation capacity — not detection, not prioritization — is the binding constraint on modern security programs.

I have the same conversation almost every week.

A security leader watches Kai investigate a few hundred thousand findings, eliminate false positives, confirm what is genuinely exploitable, and produce fixes. They are impressed. Then they say some version of: “But I'm not going to let it push changes into production.”

That is the honest objection, and it is the right one. It also isn't really an objection to automation.

We surveyed 500 CISOs at companies with $500 million or more in revenue this summer. Fifty-two percent named lack of trust in automated decisions as the single biggest barrier to adopting autonomous remediation. Governance and compliance came second at 43%. Skills and talent third at 38%. And only 32% permit automated remediation actions in their environment today.

Read that against the other numbers in the same survey. Sixty percent need more than a week to remediate a critical vulnerability. Sixty-five percent say their vulnerability management process is at least half manual. Forty-eight percent say a quarter or more of known vulnerabilities sit unremediated past thirty days.

So the industry has the capability it needs, knows it needs, and will not turn it on. That gap is not technical. It is a trust problem, and trust problems have answers.

What people actually mean when they say they don't trust it

When I unpack the objection, it is almost never “I don't think the machine can write the fix.” Coding models have been good enough at that for a while, and the people raising the concern know it.

What they mean is one of four things.

It might fix something that does not need fixing. The finding was a false positive, or it was real but unreachable, and now there is a change ticket and a regression risk for nothing.

It might break something. The fix was correct in isolation and wrong in context — a dependency bump that breaks a build, a config change that takes down a service.

I won't know what it did. Something changed in production and there is no clean account of what, why, or on whose authority.

It will do something I never authorized. The scope crept. It touched a system that was supposed to be out of bounds.

Every one of those is a legitimate engineering requirement wearing the costume of a philosophical objection. And each one has a specific answer.

Four things that have to be true before you automate a fix

One: the finding has to be proven, not scored. Scanners detect vulnerabilities not context – the vulnerability may be real but in the context of your environment it is not. This is the part that gets skipped. If you automate remediation on top of a scanner's raw output, you are automating the false positive rate and in the deployments we see, that rate runs anywhere from 83% to 99.5% of raw findings. Volume amplifies whatever quality you started with. Before Kai acts, a finding has to be confirmed as real and reachable in that specific environment, with exploitability established rather than assumed.

Two: this is a key one: you need to be able to predict what can go wrong? the fix has to be the least invasive one that works and you need to be able to predict will it break the developer’s code and will it break the application itself?

There is usually more than one way to close an exposure, and they are not equally disruptive. Resolving dependencies upstream and downstream before proposing a change so the fix does not introduce a breaking one is unglamorous work that determines whether anyone lets you do this twice.

Three: it has to be verified after the fact, not just applied. Applying a change and confirming the exposure is actually closed are two different operations. Verification belongs inside the pipeline, not in a follow-up scan next quarter.

Four: the boundary has to be yours. Not ours. You decide what class of finding gets closed with no human in the loop, what gets staged for review, and what never gets touched automatically at all. That line is a customer decision and it should move as confidence grows.

Why there are two tracks and not one

This is the design decision I get asked about most, so I will be direct about it.

Most findings, once confirmed, are unambiguous. The fix is known, the blast radius is understood, the change is routine. Holding those in a queue for a human to approve adds latency and nothing else. Those run as Kai Auto-Remediated; closed end to end without a person executing the steps.

Some findings are not like that. A patch needs a maintenance window. A change touches a system with a specific owner who needs a day. The right fix requires a business judgment nobody should delegate. Those run as Kai-Assisted fully investigated, fully validated, remediation plan built and routed to the owner, with the human doing the deciding rather than the digging.

The number we have been using is that at least 95% of findings clear before a human ever looks at them. I want to be precise about what that means, because it is easy to misread. It does not mean 95% of security work is now unsupervised. It means 95% of the investigation and execution burden is gone, and the human attention that used to be spread across everything is now concentrated on the small set of decisions that actually need a person.

That is the trade. Not less control. Less labor, and better-aimed control.

The gap between confirming and closing

There is one more piece, and it comes from a customer complaint rather than a whiteboard.

Even with all of the above, some findings cannot close instantly. The maintenance window is Thursday. The owner is out. That interval between knowing a risk is real and having it actually closed is precisely where attackers operate, and it is invisible in most programs because the ticket is technically “in progress.”

Kai Watch exists for that interval. When an exposure is confirmed, detection coverage goes up immediately and monitors for signs of active exploitation while the fix works its way through whatever process it has to work through. It does not replace the fix. It shortens the window in which the unfixed thing is undefended.

Where to start

If you are among the 68% who do not permit automated remediation today, the move is not a policy debate. It is a scoped pilot.

Pick one finding class where the fix is well understood and the blast radius is small. Let it run auto-remediated. Watch what it does, verify the closures, look at the audit trail. Then widen the boundary. Trust in automation is not granted in a procurement cycle — it is accumulated, one verified outcome at a time, and the organizations moving fastest on this are the ones that started small early rather than waiting to be convinced all at once.

The throughput gap does not close because someone decided to trust a machine. It closes because a machine earned it in a narrow lane and then got a wider one.