Working definition
Governance is the shape of the workflow, not a label applied afterward.
In GAEZLA, governed infrastructure automation means that the system keeps the operational question, available read authority, proposed change, authorization path, execution target, and returned result distinguishable. Each stage uses the record and control path appropriate to the kind of work being performed.
Governed does not mean every task waits for a new manual approval. An investigation mutation, a managed queue item, a recurring schedule, and a routine are different paths. The relevant control follows the path instead of being described as one universal gate.
Operating models
Where the control work lives.
Scripts and AI assistants can both be useful. The governance question is whether the team can identify the authority, scope, decision, execution state, and retained result without reconstructing them later.
| Operating model | Useful for | Control work the team must place |
|---|---|---|
| Standalone script | A known, repeatable task. | Identity, credentials, targets, review, scheduling, output, and recovery live in the surrounding system the team builds. |
| Read-only AI assistance | Collecting context, testing hypotheses, and explaining current state. | The assistant can inform a decision but needs a separate path when a change to the external environment is justified. |
| Direct-action automation | Executing eligible changes with fewer handoffs. | If observation and mutation share the same authority, target containment and review must be enforced elsewhere. |
| Governed automation | Operational work where authority and evidence must stay reviewable. | Reads, proposals, authorization, execution, and retained results use explicit but workflow-specific records. |
Control path
Five layers of governed infrastructure automation.
These layers describe the GAEZLA model. A particular workflow may stop after a read, use a durable proposal, or enter an already configured managed-work path.
- 01
Scope the question and target
Resolve the service, host, user, repository, environment, or other operational object before gathering broad context or preparing action.
- 02
Separate observation from mutation
Use permitted reads to collect current evidence. An external change follows a different path instead of inheriting the authority of an investigation tool.
- 03
Materialize the proposed change
Where a supported mutation path exists, retain the intended scope, current evidence, risk, safeguards, stop conditions, and rollback plan as a proposal.
- 04
Apply the workflow’s authority
Investigation proposals use operator approval and policy-required step-up. Managed queues, schedules, and routines use their own configured controls.
- 05
Execute and retain the result
Keep target, state, timestamps, returned output, failure context, and the owning proposal or managed-work record available for review.
Product example
A scanner finding is not an executed fix.
Infrastructure remediation shows why the records need to remain separate.
Observe
Retain the source finding.
Keep the configured scanner, source run, affected asset, finding evidence, and guidance attached to the observation.
Assess
Resolve a supported hardening path.
Check benchmark capability, target assignment, effective control state, and collected evidence before preparing remediation.
Act and review
Retain execution and verification separately.
Supported remediation records the attempted operation, before, desired, and after values, outcome, and any verification error.
The finding does not close itself because remediation was recommended, and a remediation attempt does not prove the desired state when verification fails.
Boundaries
What the term does not promise.
Not mandatory approval for every run
Investigation mutations can require approval and step-up. Managed jobs, schedules, and routines follow their configured execution controls.
Not unrestricted authority
Available reads and actions depend on the resolved target, configured connection, tenant permissions, and supported mutation lane.
Not guaranteed diagnosis or remediation
Investigation can retain evidence and conclusions without guaranteeing a root cause. Execution and verification can return explicit failure states.
Not an automatic universal lifecycle
Alerts, cases, proposals, queue items, findings, reports, and compliance evidence remain distinct records rather than one automatic signal-to-proof chain.
Not a certification
Governed infrastructure automation is descriptive product language here. It is not presented as an external standard, compliance result, or certification.
Evaluation checklist
Questions to ask before infrastructure automation receives authority.
- Which human, machine, and automation identities participate?
- Which targets and operations are actually in scope?
- Where does read-only investigation end and external mutation begin?
- What current evidence supports the proposed change?
- Which workflow owns approval, step-up, scheduling, or recurring authority?
- How can an operator inspect cancellation, failure, retry, rollback, and verification state?
- Which record retains the target, decision, execution result, and returned output?