Skip to main content

AI Fix Workflow

Cybrium does not stop at telling you what is wrong — it proposes and, when you allow it, applies the fix. Two workflows share the same underlying model: the AI Fix Bot, which drafts remediation plans, and Autonomous Fix, which executes approved plans in a sandboxed branch.

Screenshot: AI Fix drawer with plan and diff preview

AI Fix Bot

Open any finding and click Fix with AI. The AI Fix Bot reads the finding's context — the affected asset, the surrounding code or configuration, the framework mappings, and any related findings in the same file or service — and produces a remediation plan. The plan is a short, readable document with four sections:

  1. Root cause. A one-paragraph explanation in plain language, written for the engineer who owns the asset, not for the auditor.
  2. Proposed change. The concrete edit — a code diff, a configuration patch, a resource policy, an IAM statement — presented inline with syntax highlighting.
  3. Verification. How to confirm the fix actually remediates the finding: a re-scan command, a unit test, a manual check.
  4. Rollback. How to undo the change if it regresses something in production.

Plans are generated on demand and cached per finding. Regeneration with a new hint is one click.

Autonomous Fix

Autonomous Fix takes an approved plan and runs it end-to-end. It clones the target repository or logs into the target cloud account (using the tenant's SCM or cloud credentials), creates a new branch or change-set, applies the proposed change, commits with a descriptive message that references the finding ID, runs the verification step, and opens a pull request or change request against the default branch.

The human is always in the loop on merge. Cybrium does not merge to production; it only prepares a PR and requests review from the owners configured on the asset. If the verification step fails, the branch is abandoned and the failure is attached back to the finding.

Requires authorisation

Autonomous Fix requires explicit per-tenant enablement and SCM or cloud write scopes. Dry-run mode (plan-only, no PR) is available without write scopes.

Review and History

Every generated plan, every applied change, and every approver identity is recorded on the finding's Fix History tab, permanently — even after the finding is closed.