Skip to main content
A remediation is the planned fix for one cluster of related findings. An agent writes the plan, and once you approve it, another agent implements it. You hold two gates: approving the plan, and merging the pull request.

​
The plan

Every plan has two halves, written for two audiences.

The plan, for everyone

Three short sections with no file names and no code. Summary: what the plan is for, including the context around the finding. Execution: what will change, as high level steps. Impact: the operational effect and what to validate.

The technical plan, for engineers

The concrete change, in detail. Files, structure and approach.
Both are editable inline. If you disagree with the approach, change it before approving. What you approve is what gets implemented.

​
When a plan is written

  • Automatically, for Critical and High findings, once every question attached to them is answered.
  • On request, for any finding, at any severity.
A finding with an unanswered question gets no plan at all, automatic or on request. It is not even listed until you answer. Planning a fix on a guess about your priorities is worse than waiting. Only one active remediation exists per cluster at a time, so two people cannot start competing fixes for the same problem.

​
Execution

On approval, an agent implements the plan you approved, commits, and pushes a new branch. Repository write access is only introduced at this point, and only for this work. The fix is then validated against your own tests, so a change that breaks your build or your behaviour never reaches you as a pull request to catch by hand.

​
Outcomes

​
Status

A plan in progress is durable. Refreshing the page or coming back tomorrow finds it where you left it.

​
What Amnify will not do

  • It never pushes to your default branch.
  • It never merges its own pull request.
  • It never bypasses your branch protections, required reviews or CI.
Amnify can propose a change. Shipping it stays yours.