Using n8n, Azure DevOps, FastAPI, RAG, and AI to audit Terraform changes before merge
Infrastructure teams are increasingly using Infrastructure-as-Code to define, review, and deploy cloud resources. Terraform makes infrastructure repeatable and version-controlled, but compliance review often still depends on manual checks, late-stage audit activity, or reviewer experience. That creates a gap between how fast infrastructure code moves and how quickly teams can validate security and compliance expectations.
This automation initiative was built to close that gap. The objective was to automate Terraform compliance review during the Azure DevOps pull request process, before code is merged or deployed. The result is a working shift-left audit flow that detects changed Terraform files, audits the content, maps findings to CIS and SOC2 context, uses AI to express the finding clearly, and sends PASS, FAIL, or SKIPPED notifications to reviewers.
Why This Automation Was Needed
In a traditional process, infrastructure code is written, reviewed, merged, and deployed before deeper compliance issues are discovered. A reviewer may catch obvious mistakes during pull request review, but detailed compliance checks are hard to perform manually. This becomes even more difficult when a pull request contains multiple Terraform files or mixed changes such as README files, YAML files, scripts, and infrastructure code.
The risk is both technical and operational. A small Terraform setting can become a security or audit finding if it violates a control expectation. If this is discovered after merge or deployment, the team must revisit the code, redeploy the infrastructure, and manually collect evidence. The automation solution was designed around a simple question: can we give reviewers meaningful compliance feedback while the pull request is still open?
The Logic Behind the Automation Flow
The logic behind the automation solution is intentionally simple: treat every infrastructure pull request as an opportunity to validate compliance before risk enters the environment. The workflow does not try to audit everything blindly. It first understands what changed, filters only relevant Terraform files, and then audits the actual Terraform content from the pull request commit.
This makes the workflow practical. If a pull request has only documentation changes, the audit is skipped. If the pull request has Terraform files, the workflow processes each file. If one file fails and another passes, the result is aggregated into one pull-request-level decision. This keeps the result easy for reviewers to understand.
Trigger → Validate → Execute → Decide → Notify
The trigger is the Azure DevOps pull request event. The validation step checks changed files and keeps only Terraform content. The execution step sends Terraform content to the audit backend. The decision step determines PASS, FAIL, or SKIPPED. The notification step sends a clean email to reviewers with the result and context.
Where AI and RAG Add Value
The most important part of this automation solution is not only automation. The value increases when automation is combined with RAG and AI. Traditional automation can tell whether a rule passed or failed. RAG and AI help explain why the result matters and turn raw compliance checks into readable, evidence-backed findings.
RAG, or Retrieval-Augmented Generation, is used to bring relevant compliance knowledge into the audit process. Instead of asking the AI model to answer from general knowledge, the workflow retrieves related CIS and SOC2 context from a knowledge store. This allows the audit response to be grounded in the controls that matter for the resource being reviewed.
AI then uses the Terraform configuration and retrieved compliance context to generate a structured finding. For example, if a storage account does not enforce HTTPS-only traffic, the AI-assisted finding can explain the failed setting, the current value, the expected value, the risk, and the relevant CIS/SOC2 mapping. This makes the output easier for both engineers and reviewers to act on.
- RAG improves context by retrieving relevant CIS and SOC2 control information.
- AI improves readability by converting raw audit results into clear findings.
- The combined approach helps produce evidence-backed, reviewer-friendly notifications.
AI/RAG Request and Response Flow
The backend does not send only raw Terraform code to the language model. It builds a controlled audit context that includes the resource configuration, the applicable CIS rule, the mapped SOC2 controls, and strict output instructions. This keeps the AI response grounded in known compliance evidence instead of open-ended reasoning.
Backend request context sent to the AI model
- Role: act as a SOC2 and CIS Azure compliance auditor.
- Strict rules: use only provided CIS rules, do not invent control IDs, use severity from metadata, and return valid JSON.
- Resource: azurerm_storage_account.bad_storage with enable_https_traffic_only set to false.
- Applicable CIS rule: cis-3.1 expects enable_https_traffic_only to be true and marks severity as HIGH.
- Mapped SOC2 controls: soc2-CC6.6 and soc2-CC6.7 for logical access and security controls.
Compact prompt context RESOURCE: azurerm_storage_account.bad_storage CONFIG: enable_https_traffic_only = false CIS RULE: cis-3.1 | expected_value = true | severity = HIGH SOC2: soc2-CC6.6, soc2-CC6.7 TASK: Evaluate resource against provided CIS rules only. OUTPUT: JSON with resource, findings, status, risk, current_value, expected_value, overall_risk.
AI-generated audit response
The AI model returns a structured finding that the backend can parse and pass back to n8n. The result is not free-form text; it is a predictable JSON response that supports aggregation, branching, and notification formatting.
{
"resource": "bad_storage",
"resource_type": "azurerm_storage_account",
"findings": [
{
"cis_id": "cis-3.1",
"soc2_controls": ["soc2-CC6.6", "soc2-CC6.7"],
"status": "FAIL",
"finding": "Storage account does not enforce HTTPS traffic only",
"risk": "Unencrypted HTTP traffic allows potential interception and unauthorized access to storage account data in transit",
"attribute": "enable_https_traffic_only",
"current_value": "false",
"expected_value": "true"
}
],
"overall_risk": "HIGH"
}
This design is important because the AI is used as an audit reasoning layer, while the backend still controls the source of truth. The CIS and SOC2 context is retrieved first, then the model explains the finding using only the provided rules and controls.
Representative Backend Structure
The backend is structured as a small audit service. The exact folder names can evolve, but the separation of responsibility keeps the system easier to maintain and extend.
backend/ ├─ app/ │ ├─ api/ │ │ └─ api.py # FastAPI routes for health, ingestion, retrieval, and audit endpoints │ ├─ parsers/ │ │ └─ terraform_parser.py # Extracts Terraform resources and attributes from .tf content │ ├─ services/ │ │ └─ audit_service.py # Orchestrates parsing, retrieval, AI request, and final audit response │ ├─ rag/ │ │ └─ retriever.py # Retrieves relevant CIS and SOC2 context from the vector store │ ├─ llm/ │ │ └─ claude_client.py # Sends controlled audit prompt to the LLM and receives JSON findings │ ├─ ingest/ │ │ ├─ cis_loader.py # Loads CIS rules into the knowledge base │ │ └─ soc2_loader.py # Loads SOC2 controls into the knowledge base │ └─ models/ │ └─ schemas.py # Defines request/response models for API contracts ├─ data/ # Sample CIS and SOC2 source files ├─ chroma_db/ # Local vector store persistence ├─ tests/tf_samples/ # Terraform examples used for validation └─ requirements.txt # Python dependencies
In this structure, FastAPI exposes the service, the parser understands Terraform, the retriever brings compliance evidence, the LLM client generates structured findings, and the audit service ties everything together into one response.
Where n8n Fits in the Automation Flow
n8n is the workflow automation layer in this automation solution. It does not replace Azure DevOps, FastAPI, or the AI layer. Instead, n8n connects these systems and controls the end-to-end sequence from pull request trigger to audit notification.
The main value of n8n is orchestration. It receives the Azure DevOps PR event, extracts metadata, calls Azure DevOps APIs, applies conditions, loops through Terraform files, calls the audit backend, aggregates the results, and sends the final email notification. This makes the process easier to visualize, modify, and extend without hard-coding every integration into one application.
In the workflow, n8n also acts as the decision engine. If no Terraform files are found, n8n sends a SKIPPED notification. If the audit backend returns high-risk findings, n8n sends a FAILED notification. If the audit passes, n8n sends a PASSED notification. This branching logic turns raw automation into a usable audit process.
- Receives Azure DevOps PR events through a webhook.
- Filters changed files and selects only Terraform .tf files.
- Loops through one or many Terraform files in a PR.
- Calls FastAPI to audit Terraform content.
- Aggregates file-level findings into one PR-level result.
- Sends a clear email notification to reviewers.
How the Automation Solution Works
The automation solution connects several components into one automated flow. Azure DevOps provides the source repository and pulls request event. n8n receives the event and manages the workflow. FastAPI receives Terraform content and performs the audit logic. ChromaDB and RAG provide compliance context from CIS and SOC2 controls. Claude helps generate structured audit findings. The final result is delivered by email.
The workflow audits the actual Terraform content from the pull request commit, not a stale local file. This is important because the audit result should reflect the exact code being reviewed. The workflow also supports multiple Terraform files in one pull request, which makes it useful for realistic infrastructure changes.
Key n8n Workflow Logic
The key workflow is the Azure DevOps PR Terraform Audit workflow. It receives a pull request event, extracts metadata, gets changed files, filters only .tf files, fetches file content, calls the audit backend, aggregates results, and sends the final notification.
- No Terraform files changed: send a SKIPPED notification.
- One or more compliance findings detected: send a FAILED notification.
- Terraform files audited with no high-risk finding: send a PASSED notification.
What the Automation Successfully Demonstrated
The completed automation solution validated the end-to-end automation path. Azure DevOps PR events successfully triggered the n8n workflow. n8n identified changed files, filtered Terraform files, ignored non-Terraform changes, and handled multiple Terraform files in the same pull request. The FastAPI backend audited Terraform content and returned structured results. The workflow generated professional email notifications for PASS, FAIL, and SKIPPED outcomes.
The strongest scenario was a mixed pull request with one failing Terraform file, one passing Terraform file, and one README change. The workflow ignored the README file, audited both Terraform files, detected the failing resource, and generated one pull-request-level result. This proved the automation solution could support realistic review scenarios rather than only a simple single-file example.
Business and Engineering Benefits
The main benefit of the automation solution is earlier feedback. Reviewers can see compliance issues before code is merged, which reduces the chance of deploying non-compliant infrastructure. It also reduces manual review effort by automating repetitive checks and surfacing only the relevant findings.
- Reduces late-stage compliance rework by checking Terraform during pull request review.
- Improves consistency by applying the same audit logic across pull requests.
- Provides evidence-backed findings using CIS and SOC2 context.
- Uses AI to make audit results easier to understand and act on.
- Supports realistic pull requests with multiple Terraform files and mixed file types.
- Creates a reusable automation model for broader SDLC workflows.
Beyond Terraform Compliance
Although this automation solution focused on Terraform audit, the automation pattern is reusable. The same model can support automated testing, deployment validation, security checks, PR quality gates, release approvals, audit evidence reporting, and team notifications. The real value is the pattern: integrate triggers, validation, execution, decisioning, and notification into a repeatable workflow.
As a next step, this automation solution can be extended by adding a full CIS Azure Benchmark dataset, broader SOC2 control mappings, Azure DevOps PR comments, merge gates, remediation suggestions, and a reporting dashboard. The AI and RAG layer can also be improved over time by adding richer compliance knowledge, historical findings, internal standards, and remediation guidance.
Conclusion
This automation solution shows that infrastructure compliance does not need to remain a manual or post-deployment activity. By combining Azure DevOps, n8n, FastAPI, RAG, CIS/SOC2 context, AI reasoning, and email notification, compliance feedback can be delivered earlier and in a format that reviewers can act on quickly.
The result is a practical shift-left audit flow: faster feedback, reduced manual effort, better audit readiness, and a reusable automation foundation for modern DevOps and cloud governance. Most importantly, the use of RAG and AI turns compliance automation from a simple rule-checking process into an intelligent, contextual, and reviewer-friendly experience.
