Farewell False Positives: Building Trustworthy AI for IaC Analysis

Farewell False Positives: Building Trustworthy AI for IaC Analysis

Speakers: Emily Choi-Greene

Conference: fwd:cloudsec North America 2025

YouTube: https://www.youtube.com/watch?v=tJrfSQx_Jeg

Overview

Emily Choi-Greene, CEO and co-founder of Clearly AI, delivered a practitioner-focused talk on building reliable AI systems for analyzing infrastructure as code (IaC). Rather than presenting new vulnerabilities or attacks, this talk provided an engineering-oriented guide to applying large language models to cloud security tasks -- specifically IaC review -- while minimizing hallucinations, ensuring output consistency, and maintaining trustworthy results. Choi-Greene walked through the AI engineering stack from context ingestion (RAG and tool use) through output normalization (using BAML for typed outputs), hallucination prevention (chain-of-thought reasoning and LLM-as-judge), and the practical limitations of current models. The talk positioned AI as a force multiplier for security teams drowning in code review work, not as a replacement for human judgment.

Background

▶ Watch: AI adoption stats: 215% growth in agentic software, vibe coding security gap (2:00)

The context for this talk is a widening gap between software production velocity and security review capacity. According to data from Microsoft cited in the presentation, AI agentic software adoption is up 215% over the past year, and software releases are up 30% industry-wide. Meanwhile, organizations are not hiring proportionally more cloud security engineers. The "vibe coding" phenomenon -- where developers use AI to generate code at unprecedented speed -- is exacerbating the problem. Choi-Greene highlighted a viral example of a SaaS product built entirely with Cursor that was hacked within 48 hours of launch (API usage maxed out, subscriptions bypassed, databases compromised).

The Jevons paradox is at work: more AI-generated code creates more demand for security review of AI-generated code. The talk argues that AI should be applied to the review side, not just the generation side, and that IaC analysis is a particularly well-suited domain because it involves diverse but structured context, transforming inputs to normalized outputs, and executing repetitive consistent workflows -- all AI strengths.

Key Findings

▶ Watch: Why traditional RAG fails for IaC and tool use is better (6:00)

The central argument is that building a reliable AI system for IaC analysis requires four key engineering practices:

1. Context ingestion via tool use over traditional RAG: Standard vector-store-based RAG breaks down with IaC because similar configurations (e.g., multiple S3 bucket definitions) produce nearly identical embeddings, making semantic retrieval unreliable. Tool use (function calling) is the recommended approach, where the LLM programmatically searches codebases and retrieves contextually relevant information at runtime. This aligns with how tools like Cursor operate and integrates with MCP (Model Context Protocol) for pulling data from external systems like Jira, Slack, or cloud providers.

1. Hallucination prevention through chain-of-thought and LLM-as-judge: The most effective anti-hallucination techniques are requiring chain-of-thought reasoning (analogous to showing work in math), giving the model explicit permission to say "I don't know," and using a second LLM as a judge to validate the first LLM's claims against source material. The judge model extracts individual claims from the response and verifies each one against the original context.

1. Output normalization with BAML: BAML (from Boundary ML) is an open-source framework for enforcing typed, structured outputs from LLMs. It enables schema compliance, type enforcement, and LLM-agnostic prompting, ensuring that findings from IaC analysis conform to whatever CSPM or findings database schema the organization uses.

1. Fine-tuning as a last resort: With context optimization (RAG/tool use) and prompt engineering, most organizations can achieve reliable results without fine-tuning. Foundation model labs are continuously improving base model performance, making fine-tuning increasingly unnecessary for well-prompted systems.

Technical Deep Dive

▶ Watch: Preventing hallucinations: chain-of-thought and LLM-as-judge pattern (10:00)

The talk outlined a four-step process for structuring AI-powered IaC analysis:

Step 1: Architecture Understanding. The LLM breaks down each infrastructure component by type, file path, line number, dependencies, and tags. This structured representation enables accurate source citation -- a critical requirement for auditability and trust.

Step 2: Vulnerability Categorization. The system is configured with the specific vulnerability classes to detect: excessive permissions, open ports, broad IP ranges, missing ownership tags, and other security anti-patterns specific to the organization's threat model. This step is where customization happens -- each organization can define what they care about.

Step 3: Findings Output. Results are structured according to the organization's findings database schema, making them directly ingestible by CSPM tools, ticketing systems, or compliance platforms. BAML's type enforcement ensures every finding has the required fields populated.

Step 4: Compliance Reporting (optional). For organizations with audit mandates, the system generates structured analysis reports suitable for auditor consumption.

On the detection capabilities, Choi-Greene argued that LLMs are fundamentally better than traditional IaC scanners at contextual analysis. Traditional scanners look at specific patterns in specific files; LLMs can reason across multiple files and identify attack chains that span variables, locals, and resource definitions -- a common challenge in Terraform environments. However, she acknowledged that Terraform remains the IaC language that current LLMs handle worst, both for generation and analysis.

Key challenges include staleness (when IaC diverges from actual deployed infrastructure), context poisoning and prompt injection (especially via MCP integrations that load external data into prompts), and the ongoing need to determine when human review is still required versus when automation is sufficient.

Demo / Proof of Concept

▶ Watch: Four-step IaC analysis pipeline: architecture, categorization, findings, repo... (14:00)

No live demo was performed. The presentation included code examples showing BAML type definitions for IaC analysis outputs, prompt engineering templates for claim extraction and verification, and the overall system architecture.

Defensive Implications

▶ Watch: Challenges: context poisoning, prompt injection via MCP, and AI skepticism (16:00)

The practical recommendation for security teams is to start building AI-powered IaC review into their existing CI/CD pipelines. Choi-Greene offered a QR code linking to a curated list of AI engineering tool recommendations (mostly open source or free) for teams that want to build this capability in-house. Key recommendations include:

• Use tool use / function calling over traditional RAG for IaC context retrieval
• Implement LLM-as-judge patterns to catch hallucinations before they reach engineers
• Adopt BAML or similar typed output frameworks to ensure consistent, actionable findings
• Consider DSPy for auto-optimizing prompts based on feedback without training on user data
• Start with prompt engineering and context optimization before considering fine-tuning
• Use Claude Code as a PR reviewer for qualitative IaC feedback, including style and readability
• Be cautious with MCP integrations as a potential prompt injection vector

Key Takeaways

• AI-generated code is growing 215% year-over-year in enterprises, creating a security review bottleneck that AI itself can help address
• Traditional RAG breaks down for IaC analysis because similar configurations produce identical embeddings; tool use / function calling is more effective
• LLM-as-judge with claim extraction and source verification is the most effective hallucination prevention technique for security analysis
• BAML provides LLM-agnostic typed output enforcement, ensuring findings conform to organizational schemas
• LLMs are better than traditional scanners at cross-file contextual analysis but still struggle most with Terraform
• Fine-tuning should be a last resort -- context optimization and prompt engineering get most of the way there

About the Speaker(s)

Emily Choi-Greene is the CEO and co-founder of Clearly AI, a company focused on AI-powered cloud security analysis. She previously worked at Amazon in a security-adjacent role. She is an advocate for the BAML framework and DSPy for building reliable AI systems.