Every team running infrastructure as code has the same setup: a scanner wired into CI, a wall of findings, and a quiet agreement to ignore most of them. Those tools catch the mistakes we already know about a public S3 bucket, an over-broad IAM policy, a missing encryption flag. They are much weaker against the change someone makes on purpose: a swapped module source, a subtle permission escalation, a workflow step that quietly ships a secret out the door. Look at how SolarWinds and Codecov actually played out and the pipeline itself was the attack surface and most IaC tooling would have waved those changes right through.
So I set out to answer an uncomfortable question: if someone slipped a malicious change into our Terraform, Kubernetes, or GitHub Actions config, would anything stop it? The approach I landed on combines two things that are individually old news abstract syntax trees to understand the structure of a change, and a small, cheap language model to read the diff in context and judge intent. Neither is magic on its own. Together they caught changes that pattern-based scanners never flagged, sorting the boring diffs from the dangerous ones about nine times out of ten in testing.
This is not a victory lap, though. I will spend real time on where it went sideways: legitimate security-hardening changes that looked identical to attacks, refactors that tripped every anomaly check, and a false-positive rate that would've trained developers to click past the tool inside a week if I would let it auto-block. That's why it ended up with a human in the loop for anything ambiguous and automatic blocking only when it was very sure. You'll leave with a grounded sense of where AI helps in DevSecOps and where it's just noise, a way to think about your own IaC as something an attacker will target, and a strong opinion about the fastest way to kill a security tool: make people stop trusting it.