Use of Automated and Assisted Tools in IaC Authoring

Writing and changing Infrastructure as Code is frequently supported by automation (templates, generators, normalisers, snippets, scripts) and by assisted mechanisms (suggestions and composition).
These tools increase productivity, but introduce specific risks: changes with low explainability, insecure defaults, excessive permissions, unexpected resources and involuntary exposure of sensitive information.

This document defines what is acceptable, what is prohibited, and which validations and evidence are mandatory to ensure that automation/assistance does not reduce control, traceability and auditability.

1) Base principle: suggestion ≠ decision

Regardless of its origin, the proposed IaC is always treated as untrusted input.
The decision to execute (apply) is always human and formalised by gates and approvals (proportional to risk).

2) Acceptable vs prohibited patterns

✅ Acceptable (with control)

Generating drafts of IaC (skeletons) for subsequent human review.
Normalising formatting/structure (e.g. reorganisation of files), provided there is a plan and validations.
Generating documentation and comments (non-executable) from the code.
Creating change proposals in branches/PRs with mandatory execution of plan and scanners.

❌ Prohibited (by default)

Any mechanism that executes apply in production without gates and formal approval.
“Bulk” automatic changes without explainability and without correlation with risk/impact.
Publishing plan, detailed logs or sensitive diffs to external systems without minimisation/redaction.
Introducing new dependencies/modules/providers without governance (allowlist + pinning + review).

Exceptions are acceptable only with a formal record (TTL, owner, compensations) and approval according to criticality.

3) Typical error classes in automated/assisted IaC

These classes must be assumed as baseline risk and covered by semantic validation:

“Hallucinatory” / unexpected resources: creation of unintended resources (services, endpoints, rules).
Insecure defaults: encryption switched off, logging absent, “open” permissions.
Overly broad IAM: wildcards, admin roles, improper cross-account access.
Network exposure: permissive security groups, public ports, flat networks.
Accidental destruction: implicit destroy, recreations, destructive replacements.
Masked drift: indirect changes by providers/modules, uncontrolled upgrades.
Exfiltration through logs/artefacts: improper publication of topology, IDs, endpoints and secrets.

4) Mandatory validations (gates) and minimum evidence

4.1 Minimum gates (always applicable)

Lint/syntax: validation of format and consistency.
Security scanning: misconfigurations, exposures and dangerous patterns.
Policy-as-code: blocking of critical violations.
Secret scanning: preventing secrets in repos/logs/artefacts.

4.2 Semantic validation of the `plan` (mandatory when applicable)

Impact of the plan: creation/change/destruction per resource and environment.
Effective permissions: increase in privileges, wildcards, admin roles.
Exposure: public endpoints, permissive network rules, public storage.
Encryption/logging: critical resources without minimum guarantees.
Unexpected diffs: upgrades and indirect changes.

4.3 Minimum (auditable) evidence

plan associated with the PR/MR + commit + environment.
Scanner/policy reports associated with the same PR/MR.
Record of approvals before apply (who, when, why).
Retention of artefacts proportional to risk.

5) Handling of external systems

Any external system that processes:

repository content,
plan,
logs,
diffs,
outputs,

must be treated as a security dependency:

classified and authorised organisationally;
subject to logging/retention and isolation requirements;
subject to context minimisation rules (no secrets / no infra topology);
subject to contractual obligations when applicable.

⚖️ Proportionality L1–L3

Dimension	L1	L2	L3
Use of automation/assistance	Permitted with review + blocking validations in the pipeline	Permitted with blocking gates	Permitted with gates + reinforced SoD
Semantic validation of the `plan`	Recommended	Mandatory	Mandatory (reinforced)
Approval before `apply`	Simple	2nd reviewer	Dual approval + change window
Evidence and retention	Basic	Mandatory	Mandatory + reinforced retention
External integrations	Restrict	Minimise and redact	Minimise+redact + reinforced control

✅ Control checklist per project

Automation/assistance is used only for proposals (not for uncontrolled execution)
Minimum gates active (lint, scanning, policies, secret scanning)
Semantic validation of the plan applied when relevant
plan and reports correlated with the PR/MR + approval
External integrations follow context minimisation and redaction
Exceptions are formal, temporary and with compensations

1) Base principle: suggestion ≠ decision​

2) Acceptable vs prohibited patterns​

✅ Acceptable (with control)​

❌ Prohibited (by default)​

3) Typical error classes in automated/assisted IaC​

4) Mandatory validations (gates) and minimum evidence​

4.1 Minimum gates (always applicable)​

4.2 Semantic validation of the plan (mandatory when applicable)​

4.3 Minimum (auditable) evidence​

5) Handling of external systems​

⚖️ Proportionality L1–L3​

✅ Control checklist per project​