Working definition
Automated does not mean automatic.
Automated infrastructure remediation is running defined change logic against a scoped target, then keeping a result you can check against the intended state. GAEZLA has two remediation paths: a change the AI drafts from an investigation, and changes under supported hardening benchmarks.
Neither starts by itself. The AI's change waits as a proposal until an operator approves it. A hardening change is confirmed by an operator, or proposed by the AI and approved the same way. A completed run is not a verified change: the per-setting results show what actually happened.
Separate records
Observation, proposal, execution and result are different facts.
Keeping them apart stops a recommendation, a queued job or a finished run from being shown as proof that the target reached the desired state.
| Record | What it establishes | What it does not establish |
|---|---|---|
| Scanner finding | A scanner on your appliance observed an issue on an asset, with evidence and guidance. | That a change exists, ran or worked. A finding is marked resolved when a later scan from the same scanner no longer reports it. |
| AI proposal | The exact change the AI drafted, with its reason and evidence from the same case, fingerprinted at approval. | Approval or execution. An operator approves it; nothing in GAEZLA can. |
| Hardening audit | Each applicable control returned pass, fail, skipped, not applicable, error, unsupported, permission denied or authentication failed. | Permission to change the target, or proof that a later change succeeded. |
| Change result | What each setting was, what the benchmark requires and what it is now, the outcome and any failure stage. | The closure of a scanner finding, or proof beyond what the result itself records. |
Remediation path
From an observed risk to a result you can check.
This is the path in GAEZLA. Not every finding maps to a benchmark control, and not every executor can change its target.
- 01
Keep the observation intact
A scanner finding keeps its scanner, source run, evidence and guidance. It is an observation, not authority to change anything.
- 02
Investigate before changing
The AI can read the finding, the asset and live state through the integrations in scope, and keep that evidence in a case.
- 03
Choose the path
A change through a vendor API, a signed playbook or a pull request is drafted as an AI proposal. A benchmark control becomes a hardening run, where the benchmark supports changes.
- 04
An operator approves
An AI proposal needs an operator, with multi-factor authentication if you require it. A hardening change is confirmed by an operator in the console, or proposed by the AI and approved like any other change.
- 05
Run signed work
Host work is signed and placed on the target agent's queue. The agent refuses unsigned work and checks the signer before anything runs.
- 06
Read the result, setting by setting
For each setting, what it was, what the benchmark requires and what it is now show whether the target reached the intended state. A structured error shows whether the attempt stopped at the precondition, the write or the verification.
Supported scope
The executor decides whether remediation is available.
Agent-based hardening
Audit and change.
Benchmarks that run as agent playbooks, such as those for Linux and Windows hosts, support both. The effective controls are built into a signed workload and queued for the assigned agent.
API-based hardening
Audit only.
Cloud and productivity-suite benchmarks are checked through their APIs. These executors refuse changes, and the benchmark shows audit-only instead of offering a write path.
Selected controls
Scope narrower than the benchmark.
A run can carry a selected list of controls. Each must belong to the assignment's benchmark, and the request is refused if that scope changes before the work is queued.
Evidence model
A successful request and a reached state are not the same thing.
Returned hardening evidence is validated and size-bounded before it is stored. For a change, each setting keeps the state observed around it.
Before
What it was
The value before the change, and whether it existed at all.
Required
What the benchmark requires
The intended value, recorded instead of left implicit in a script.
After
What it is now
The value after the change, kept next to its own outcome: not attempted, succeeded or failed.
Failure stage
Where did the attempt stop?
At the precondition, the write or the verification, with an error code and message.
Failure is evidence
Unsupported and unsuccessful outcomes stay visible.
Unsupported executor
The executor cannot perform the requested control or change.
Authentication or permission failure
The target could not be authenticated to, or the account lacked the rights the operation needs.
Precondition or write failure
The attempt did not pass its precondition, or could not apply the requested value.
Verification failure
A write may have been attempted, but the value that came back does not show the desired state.
Control still failed
A run can finish while individual controls still show failed or other non-passing outcomes.
Boundaries
What the GAEZLA remediation path does not promise.
No automatic finding-to-change chain
A finding does not start a run. Recommending or running a change does not close it; a later scan that no longer reports it does.
No universal benchmark coverage
A change needs an applicable benchmark, a supported executor, a valid assignment, effective controls and a reachable, authorised target.
No guaranteed successful change
Execution can return unsupported, authentication, permission, control, write or verification failures for an operator to review.
Evaluation checklist
Questions to ask before automating infrastructure remediation.
- Which scanner produced the finding, and is that provenance kept?
- Can the AI propose a change, and who has to approve it before it runs?
- Does a benchmark exist for the target, and does its executor support changes or audit only?
- Which assignment, controls, overrides and parameters define the change?
- How is host work signed, and does the host check the signature?
- Are what it was, what the benchmark requires and what it is now kept for each setting?
- Can a completed run still show failed controls?
- What closes a finding: a recommendation, a run, or a later scan?