AI-powered cloud remediation: from finding to a reviewed fix
Security tools got better at finding things. The bottleneck was never finding — it was fixing. A security team that surfaces hundreds of findings a week and has engineering time to fix a few dozen will always have a growing backlog, however well tuned the detection is.
AI-assisted remediation goes at that bottleneck. Not by reducing finding volume — the findings are real and need fixing — but by shortening the work between "identified" and "resolved" for each one.
Why generic LLM suggestions fail
The obvious approach is to pipe findings into a general-purpose LLM and ask it to produce a fix. This works poorly in practice, for a specific reason: cloud security remediation is context-dependent in ways a general LLM cannot know without being told.
Consider a finding: "Lambda function payment-processor-prod has a role with s3:GetObject on *." A generic LLM will suggest: "Restrict the IAM role to only the specific S3 bucket the function needs to access." Technically correct. But which bucket? What is the ARN? Are there multiple buckets? Is the function deployed by Terraform, CloudFormation, or CDK? Is the role shared with other functions?
A useful fix starts from context the platform already holds: the resource, its account and region, the rule that failed and the rule's remediation guidance. In Onam, every finding carries an AI fix prompt built from that context — it names the resource and your cloud's tooling — which you paste into an assistant to draft the CLI command, Terraform change or console steps, then review before applying.
AI Code Fix: corrected source files on a fix branch
AI Code Fix works on the findings from a completed SAST scan of a repository — source files flagged by static analysis. It does not write tests, generate infrastructure-as-code patches or fix DAST results; those have no source file to rewrite.
| Step | What happens |
|---|---|
| Select | You choose the scan and which severities to fix. Findings your team marked as false positives are left out. |
| Group | Findings are grouped by file, so every issue in one file is fixed in a single pass. |
| Ground | A large language model receives the whole file, every finding in it, and the rule's guidance — the recommendation and a safe example in the same language where one exists. |
| Constrain | The model is told to fix only the listed issues and keep indentation, names and style unchanged. |
| Hand over | Corrected files are committed to a new fix branch and pushed for review. Nothing merges and nothing deploys on its own. |
For a hardcoded database password, the fix branch carries the same file with the literal replaced by an environment-variable lookup, and nothing else in the file changed. A developer reviews the diff, runs the tests and opens the pull request through the team's normal process.
Attack-path stories: why the fix matters
The third piece addresses a different bottleneck: communication.
Attack path analysis produces a graph — nodes and edges, resource IDs, MITRE technique codes. That is precise for a security engineer and hard going for a CISO preparing a board update or a GRC team answering an auditor.
In Onam, each attack path opens as a step-by-step story: where the path starts, each hop with its MITRE ATT&CK tactic and technique, the data store or key it ends at, and a remediation step for each hop. The choke point — the resource that appears in the most paths — is marked, with the number of paths that fixing it would block. The story and the graph are drawn from the same path data, so they stay in sync.
Data handling
AI Code Fix sends the full content of each affected file — and only files with findings — to the language model that writes the fix. The Git token it uses needs read access and permission to push a branch, and it is not stored. Every run is audit-logged: who asked, for which scan and which repository. The AI fix prompt on a posture finding is text you copy into the assistant of your choice, so you decide where it goes.
Making AI remediation part of the workflow
The most common mistake in AI remediation rollout is treating it as a replacement for security engineering judgment. It is not. Every generated fix requires review before deployment. The model sees the file, the finding and the rule's guidance — it does not understand your team's operational constraints, your change management process, or the business reasons a particular configuration might be intentional.
The right workflow is: AI drafts, an engineer reviews, an engineer approves, your pipeline deploys. The AI shortens the drafting. It does not replace the judgment — and it should not.
What remains is review, approval and change management — timelines bounded by process rather than by how long it takes someone to write the change.