Name: When the Robot Writes the Bug: A Merge Gate for AI-Generated Code
Start: 2026-11-05T14:15:00-0800
End: 2026-11-05T15:00:00-0800

When the Robot Writes the Bug: A Merge Gate for AI-Generated Code

Thursday November 5, 2026 2:15pm - 3:00pm PST

Room: Grand Ballroom B (Street Level)

AI coding assistants now write a real share of what we ship, and a stubborn fraction of that code is insecure: SQL injection, hardcoded secrets, weak crypto, unsafe deserialization. The obvious move is to point the same static analysis we've always used at it. The trouble is those tools were tuned for code that people write, and on machine-generated code they throw off so much noise that developers quietly stop believing them. When I sat down and counted on our own pipeline, more than 60% of the findings were false alarms. And once that happens, the gate is finished. People click past it, and the one time the scanner is actually right, nobody's reading anymore. A gate you don't trust is worse than no gate at all.

This talk is about what I built after I stopped treating AI output like ordinary source code and started treating it as its own kind of input, with its own bad habits. It makes three moves before anything merges, and I'll run all three live. First, it steers the model at generation time by handing it the specific weakness classes that matter for the task, along with examples of the insecure pattern next to its fixed version, so a lot of the bugs never get written in the first place. Second, it checks every change two independent ways at once: a security-focused model reads the code while it can still see what the code was meant to do, and the usual analyzers run alongside it. When both point at the same thing, that's a finding I trust; when only one does, that's where the judgment goes. Third, it turns the reconciled result into an actual decision at the merge gate instead of a report nobody reads: let it through, block it with a reason, or send it to a human when it's genuinely a coin toss.

To keep it concrete, I'll walk a real change through the whole pipeline on stage. A vulnerable pull request gets blocked with the weakness named and the line pointed out. A clean one passes and gets stamped with what was checked. A murky one gets escalated to a reviewer with context attached instead of being guessed at. Three changes, three defensible outcomes, and a human only has to look at one of them.

Then I'll show whether it worked. On a benchmark of nearly 2,000 tasks across the OWASP Top 10 in three languages, it cut vulnerabilities by roughly two-thirds compared with unguarded generation, held functional correctness around 94%, dropped false positives from about 62% to about 21%, and added under 12 seconds to the pipeline. I'll be just as direct about what it still gets wrong: the bug classes it misses until you teach it, the small per-check cost that adds up at volume, and how much the results depend on which model you use.

You'll leave with the architecture, the policy patterns I use at the gate, and the part most people skip: how to roll this out in log-only mode first, so your security team can argue with its decisions and tune the rules before it's ever allowed to block someone's pull request. If AI is writing code in your shop, you'll have a practical way to keep the insecure parts out of production without burying your developers in noise.

Speakers

Maulik Bhatt

Senior Software Engineer, Amazon

Senior SDE at AWS, where I specialize in building scalable cloud services and ML orchestration systems. Passionate about designing enterprise-scale production AI systems and distributed architectures.

linkedin.com/in/maulik-bhatt/... Read More →

Thursday November 5, 2026 2:15pm - 3:00pm PST
Room: Grand Ballroom B (Street Level)

Implementation

Audience Intermediate

OWASP Global AppSec USA 2026

Maulik Bhatt

Get help with the event

OWASP Global AppSec USA 2026

Maulik Bhatt

Sign up or log in to save this to your schedule, view media, leave feedback and see who's attending!

Get help with the event