Back to Demos
Governed Automation

Self-Healing

Findings that fix themselves, under a gate. Every change is proposed first, checked against policy, applied with a rollback point, and then verified against the cloud rather than assumed.

Watch it run — sign-up to result

Stage 1 of 6
aribot · Self-Healing
RemediationsGate journeyAttestationsLedgerTerraform PRsROI

Findings in scope

—

not measured yet

Auto-fixable

—

not measured yet

Applied

—

not measured yet

Confirmed by re-check

—

not measured yet

Proposed change

Nothing proposed yet — connect an account and choose a scope.

Safety gates

No gate has ruled yet — a change with no decision is not a change that passed.

Useryou do this step

Connect an account

GOES IN

Read-only cloud access

COMES OUT

working…

ILLUSTRATIVE SEED DATA — NOT CUSTOMER DATA

1,240 findings

Run log
t+0.0s [User] Connect an account
working on: Read-only cloud access

The problem

Remediation backlogs grow faster than teams can clear them. The findings are known, the fixes are routine, and the work still sits for months because every change needs a human to write it.
Teams that do automate remediation usually cannot say what changed. The tool reports success on dispatch, so a fix that silently failed in the cloud is indistinguishable from one that worked.
Automation without a gate is the reason most teams refuse it. Nobody wants a system with production write access and no approval step, no blast-radius statement, and no way back.

What Aribot does

  • Every fix is produced as a dry run first. You see the exact change, the resources it touches, and what it would cost before anything is applied.
  • Policy gates evaluate the proposal, and they fail closed. If a gate cannot be evaluated the change is held, not waved through — an unrun check is never recorded as a pass.
  • A rollback checkpoint is created before the change, not after. Reverting is a normal operation rather than an incident.
  • Outcome is verified against the cloud after the fact. A change is marked healed only when the resource is re-read and confirms it; dispatch alone proves nothing.
  • Where verification is not possible, the record says so. The status stays 'unverified' rather than being upgraded to success by silence.
  • Scope is explicit: which accounts, which resource types, which severities. Everything outside it is refused rather than quietly included.

Watch the recorded demo

2:44

The run above is interactive. This is the same ground walked through on video, if you would rather watch than click.

Other cuts of this

More on the Ayurak AI channel.

Who this is for

A cloud engineer drowning in findings

When it comes up

Two hundred findings, most with an obvious fix, and no safe way to apply them at volume without becoming the person who broke production.

What changes

Each change passes admission gates first, and a gate refusing a change is recorded as a save rather than as a failed job.

A change manager

When it comes up

Automation that runs outside the change window is the reason automation gets switched off after one bad night.

What changes

The change-window gate refuses out-of-window work and nothing is altered, with the refusal on the record.

An auditor asking what actually changed

When it comes up

Remediation reports say 'resolved', which usually means the instruction was sent, not that the resource changed.

What changes

A finding closes when the resource has been re-read and agrees, and the re-check is stored separately from the execution.

Illustrative example — not customer data

1,240
Findings in scope
matched to an available fix
310
Auto-healed
applied and re-verified against the cloud
46
Held at the gate
policy refused or could not be evaluated
884
Awaiting approval
dry run ready, no change made

In the product

  1. 1
    Group the backlog by fix
    Findings that share a remediation are grouped, so one review covers many resources instead of one ticket each.
  2. 2
    Generate the plan (dry run)
    The exact change is rendered — resources, parameters, expected effect — with nothing applied. This is the artefact you review.
  3. 3
    Let the gates rule
    Policy, scope and blast radius are evaluated. Refusals carry a reason; a gate that cannot run holds the change rather than passing it.
  4. 4
    Approve and apply
    A rollback checkpoint is taken first. The change is then applied to the named resources only.
  5. 5
    Verify, then close
    The resource is re-read from the cloud and compared against the intended state. Only a confirmed match closes the finding; anything else stays open and says why.
Book a walkthrough All demos

Why teams use this

Use cases and case studies

Use case

Fix cloud findings in bulk behind an approval gate

Aribot turns routine cloud fixes into dry runs behind policy gates, and a finding closes only when the cloud confirms the change.

Read the use case One-pager Carousel

Case study · Self-healing · Customer zero

Two out of three fixes never touched production

49 of 73
remediation runs that were dry runs only, February to September 2026
8
live fixes applied and then verified against the resource

All use cases and case studies