Fixes that apply themselves, only when it is safe.

Automation that fixes things also needs something that can say no

Most security teams already know what is wrong. The scanners have run, the findings are ranked and the fixes are often well understood: make a storage bucket private, narrow a role, close a port, raise a library to a safe version. What stops the fix is not knowledge. It is the fear that an automatic change will reach further than intended, break something that was working, or report success while the hole is still open.

So known issues wait in a queue. Every day they wait, the window an attacker needs stays open. The opposite answer, a script that patches whatever it finds, trades one risk for another: nobody can say afterwards what it touched, why it was allowed, or whether it helped. Neither answer survives a conversation with an auditor.

Aribot takes a third route. Every fix is proposed as a plan you can read, then has to clear a set of gates before anything is written. A gate that cannot reach a clear answer holds the change, which is what failing closed means. The fixes that clear the gates land quickly; the ones that do not are stopped and explained, and both outcomes are on the record.

Four people who have to say yes before automation can act

The life of a fix, from rehearsal to sealed record

Every remediation follows the same path, whether it was proposed by a rule, by an engineer or by an AI agent. The order matters: nothing that can change your estate happens until the plan has been read, checked and, where you require it, approved.

1. 
   1

   Dry-run plan

   The fix starts as a rehearsal. Aribot works out what it would change, on which resources, and what finding it is expected to close. Nothing is written. Findings that share one fix are grouped, so a single review can cover many resources.

2. 
   2

   The diff

   You see the exact change: the configuration as it is, the configuration as it would be, and the steps to undo it. For code and infrastructure-as-code fixes, the diff is the one that would go into the pull request.

3. 
   3

   Policy gate

   Your rules decide first: which kinds of fix may run, in which environments, at what severity, and whether a rule is locked so that no autonomy setting can override it.

4. 
   4

   Blast-radius gate

   How far does the change reach? If it touches more than your limit allows, it is held before any production write, and the reason is recorded. A stop here is the protection working.

5. 
   5

   Posture gate

   The change is only admitted if it does not make the system easier to attack. Earlier fixes must stay fixed: a change that would reopen a closed finding does not pass.

6. 
   6

   Attack re-check

   The fix has to break the attack path it was aimed at. Changing a setting near it is not enough. Fixes proposed by AI get a second, independent test before they can go further.

7. 
   7

   Approve

   If your approval rules require a person, the fix waits for them with the plan, the diff and the gate results in front of them. High-impact fixes can require sign-off from several named approvers.

8. 
   8

   Apply and verify

   The change is applied in one all-or-nothing step, through the cloud provider or as a pull request. Then the resource is read again. The finding closes when the resource agrees. Sending the instruction does not close it.

9. 
   9

   Sealed record

   The plan, every gate decision, the approver and the outcome are sealed into a tamper-evident record. Anyone with access can re-check a record later and see whether it was changed after it was saved.

10. 
    10

    Rollback point

    Before the change, the state needed to reverse it is kept. If something downstream disagrees with the fix, an owner rolls it back as a normal action, and the rollback is recorded too.

You decide where the line sits, rule by rule

Autonomy is not one switch. Approval rules decide, for each remediation, whether it applies on its own, waits for a person, or is blocked outright. A rule can match on the kind of fix (cloud, code, configuration, infrastructure as code, design or process), the severity, the environment, how it is delivered (directly through the cloud provider or as a pull request), the control family it serves and a resource pattern.

Everyone in the company can see the rules. Only owners and security managers can change them. Production can be held to a stricter setting than staging and development, and a single emergency control stops all automatic changes while you look at something.

One set of gates for a cloud setting and a line of code

Some fixes belong in the cloud account: a public bucket, an over-broad role, a database that accepts connections from anywhere. Aribot applies those through the provider, after the gates, and reads the resource back to confirm the change took.

Other fixes belong in code: a dependency with a known vulnerability, an unsafe default in an application, a Terraform module that will recreate the problem on the next deploy. Fixing the live resource alone would be undone by the next pipeline run. For these, Aribot opens a pull request on GitHub with the diff, after you have given consent for that repository, so your engineers review and merge it the way they review everything else. The same gates run before the pull request is opened.

One morning at a fictional freight company

The company, people, times and figures below are invented to show the shape of a real working day. Nothing here describes a customer.

1. Monday, 09:40

   A cloud scan at Fernhill Logistics, a fictional freight company, finds that a storage bucket holding shipment manifests allows public read, the service role behind the customer portal can read every bucket, and the orders database accepts connections from the whole network. Aribot links all three to one attack path on the portal's threat model.

2. 09:41

   Three dry-run plans appear on the self-healing overview. The role fix is first: narrow the portal role to the two buckets it reads. The plan, as written, would also edit four shared roles used by other teams.

3. 09:41

   The blast-radius gate holds it. Fernhill's rule allows a production fix to touch at most five resources without a wider review; this one touches fourteen. Nothing is changed. The overview marks it as a hold, with the reason.

4. 09:52

   Priya, the platform lead, narrows the scope to the portal role alone. The revised plan touches five resources and clears policy, blast radius, posture and the attack re-check. Fernhill's rule says production identity changes need a security manager, so it waits.

5. 10:05

   Marcus, the security manager, reads the plan, the diff and the gate results, and approves. The change is applied, the role is read back and agrees, and the finding closes. The bucket and database fixes, both inside Fernhill's auto-apply rule for this kind of change, have already landed and been verified.

6. 10:20

   The portal's attack path now stops at the service. The record shows every step: who proposed, which gates held and passed, who approved and what was re-read. When Fernhill's auditor asks about change management next quarter, this record is the answer.

Every change keeps its way back

A fix can be correct and still disagree with something nobody listed. The public website might have been reading images from the bucket you just made private. A batch job might have relied on the role you narrowed. Gates reduce these surprises; they cannot remove them.

So the plan carries its own undo steps, and the state needed to reverse the change is kept before it is applied. If a dependent system complains, an owner chooses roll back on the remediation. The resource returns to its earlier state, the rollback is recorded with who did it and why, and the original finding is reopened so the next plan can solve the real problem. A rollback is an ordinary operation, and nobody has to hold an incident review.

What you see once you sign in

The self-healing area is built for the people who have to trust it. Every number states exactly what it counts, and every refusal is shown as what it is: the system stopping a change that did not meet your rules.

Part of one path: AI readiness, Aribot, Trust

Self-healing is not a separate tool bolted on at the end. It sits in the middle of the Ayurak platform. The free AI readiness self-assessment tells you where you stand. Aribot finds what is wrong in your designs, code and cloud, and fixes what is safe to fix under your rules. Ayurak Trust turns the record of those fixes into evidence for the frameworks you report against, with assessment templates by Aristiun.

Evidence that maps to the controls you already report on

Aribot does not certify you against anything. What it gives you is a complete, checkable record of each automated change, which is what these public standards ask you to show when changes are made to systems in scope.

Frequently asked questions