Working definition
Governance is enforced in the path, not added afterwards.
In GAEZLA, governed infrastructure automation means each kind of work has its own path and its own control. A read runs straight away. A change the AI asks for becomes a proposal that an operator approves. A defined playbook runs as signed work on the agents it is assigned to.
Governed does not mean every run waits for a new approval. A schedule an operator set up runs its playbook on time, and an unattended routine reads without changing your systems. What matters is that you can tell which path each piece of work took, and who authorised it.
Operating models
Where the control work lives.
Scripts and AI assistants can both be useful. The question is whether the team can name the authority, scope, decision and result of each change 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 whatever the team builds around it. |
| Read-only AI assistant | Gathering context and explaining current state. | Every change is still made by hand, outside the assistant, with no link back to the evidence. |
| AI with a service account | Making eligible changes without handoffs. | Reading and changing share one standing credential, so containment and review must be enforced somewhere else. |
| Governed automation | Work where authority and evidence must stay reviewable. | Reads, proposals, approval, execution and the record each use their own path and control. |
Control path
Five layers between the AI and a change.
These layers govern each change the AI asks for through the SDK. A request can stop after a read; managed playbook work follows the controls described below.
- 01
Know who is asking
Every operator signs in, and the MCP endpoint has no anonymous path. Permissions are the operator's console roles, checked again on every call.
- 02
Separate reading from changing
Reads run straight away. A change is drafted as a proposal instead of inheriting the authority of a read. An integration can also be set read-only; then changes there are refused.
- 03
Fingerprint the proposed change
The proposal carries its reason, evidence from the same case and its exact content. It can declare preconditions, stop conditions and a rollback plan. It is fingerprinted at approval, so it cannot be tampered with on the way.
- 04
Let an operator approve
An operator approves, in the console or in their MCP client, with multi-factor authentication if you require it. Approve and execute refuse machine tokens, and nothing in GAEZLA can approve a proposal.
- 05
Run exactly that, and record it
GAEZLA runs exactly what was approved, nothing more. Each decision records who approved it, over which channel, under which requirement, when, and what ran.
Three paths
Each kind of work has its own control.
GAEZLA does not claim one gate covers everything. It names the control each path uses.
AI-proposed change
Approved by an operator, each time.
A change the AI asks for becomes a proposal. It runs once an operator approves it, as an API call, a signed playbook or a pull request.
Managed playbook work
Signed, assigned and visible.
Agents refuse unsigned work, and each run shows its state and output. An operator with the schedules role sets up recurring runs; the AI's SDK only reads schedules.
Unattended routine
No changes when nobody is watching.
A routine runs on a schedule and cannot change your systems or propose a change. It may send mail from your shared mailbox to recipients you allow, under the routine's own approval.
Each path ends in a record you can read: the proposal and its decision, the queue item and its output, or the routine run and what it found.
Boundaries
What the term does not promise.
Not an approval on every run
Changes the AI proposes need approval. A schedule an operator set up runs its playbook without a new approval each time. An unattended routine changes nothing on your systems; it may only send mail it has standing approval for.
Not unrestricted authority
What can be read or changed depends on the integrations you configure, the operator's console roles and whether an integration is set read-only.
Not guaranteed diagnosis or remediation
A case can keep its evidence without finding the cause. Execution and verification can fail, and the failure is recorded.
Not an automatic lifecycle
Alerts, cases, proposals, queue items, findings and compliance evidence stay separate records. An alert does not open a case by itself, and a case does not produce compliance evidence.
Not a certification
Governed infrastructure automation is GAEZLA's description of how the product works. It is not an external standard, a compliance result or a certification.
Evaluation checklist
Questions to ask before infrastructure automation receives authority.
- Which people, agents and machine credentials can act, and which can approve?
- Can a token, a schedule or the AI itself approve a change?
- Where does reading end and changing begin? Can changes be switched off per integration?
- What evidence must a proposed change carry?
- Is the approved content fingerprinted, and checked again before it runs?
- Which work runs without a fresh approval, and what limits it?
- What is recorded for each decision and each run?