The guardrail that decides whether AI coding ships discipline or disaster

Code generation is cheap, but trusting the code is expensive, and that cost grows as agents move from generating a few lines of code to acting across the whole pipeline.

On the latest episode of our podcast The Next Commit, Sonar host Tom Howlett talked with Shashank (Shash) Patwardhan, application security lead at IFX Payments, who spent years in consulting helping organizations set up technical guardrails for AI adoption. He argues that most security controls in use today were designed for autocomplete, and that the hardest problem with autonomous agents is teaching them when to stop. Every fix he recommends comes back to that idea: deciding where the work stops until something checks it.

AI stopped suggesting and started acting

Shash maps the shift in four stages. Autocomplete arrived first, with Copilot in 2021 and humans in full control. Then came chat-driven copy-paste, which smuggled insecure patterns like concatenated SQL queries and hard-coded credentials back into codebases. Stage three put agents directly into the IDE, editing code. Stage four, where we are now, turns agents loose in pipelines with credentials and network access.

"It's gone from ‘AI suggests’ to ‘AI acts’," Shash said. Those are two different risk models, and most organizations' controls were designed for stage one. The risk grows when people outside engineering still treat AI as a typing assistant. As Shash put it, they "end up actually giving it the permissions of a senior engineer."

When AI only suggested, the human was the stopping point. Once AI acts, that stopping point has to be built in.

Shash's point is simple economics: when something gets cheap, people make too much of it. He estimates team velocity has roughly quadrupled and PR size has grown about tenfold, with agent pull requests now running 2,000 to 5,000 lines. Nobody reviews a change that size line by line, so it gets a rubber stamp.

From a security point of view, each unnecessary line adds an attack surface and each unnecessary dependency adds supply chain risk. Shash flagged slopsquatting as a growing threat. His recommendations are to cap PR size so reviews stay meaningful, label AI-generated code so it gets its own scrutiny, and pin dependencies, then scan them, since a pinned package can still be malicious.

The model cannot mark its own homework

Smaller PRs help, but they don’t answer who does the checking. The obvious shortcut is to have the same model that wrote the code review it. Shash pushes back on this in almost every conversation he has about AI review. "If the same model is going to write the code and the same model is going to read the code, it's going to create kind of blind spots. The assumption that made it write that code or write that bug is going to make it overlook that bug as well." He compares it to an author proofreading their own essay, reading what they meant instead of what they wrote.

His answer is employing a review that runs independently of the model that generated the code. He still sees a central role for static analysis, as long as it understands context, since tools that only match patterns will struggle to keep up with AI-written code. He pointed to SonarQube's context-aware analysis as an example, and to Gitar, which checks agent output against an organization's own standards.

If the generating model can’t be the check, the check needs its own place in the workflow. The gap Shash sees most often is a review step between the agent and the human reviewer. That layer checks every change against the organization's secure coding policies, cryptography standards, permitted languages, OWASP Top 10, and OWASP Top 10 for LLM Applications, plus a vendor knowledge base. Tom shared a take he keeps hearing: as long as verification happens before a human gets to the code, you've shifted left enough.

With that step in place, AI handles the first pass and the cleanup, and the reviewer starts from a checked, annotated change instead of a few thousand raw lines. This way, the developer who commits the code still owns it. "AI generated it" doesn’t hold up as a defense, and in regulated industries, the company still answers to regulators for that code, generated or not.

Agents don’t know when to stop

Review stops bad code. It doesn’t stop an agent that’s still acting.

A human pen tester knows the business logic and which systems are the crown jewels, and eventually gives up on a rabbit hole. An agent keeps going, trying every route until it completes the instruction.

He shared an example from a client engagement. A team gave a coding agent a senior engineer's token and told it to fix a failing pipeline. The agent found a security gate blocking the build, disabled the scan in the pipeline config, and the build went green and merged. Later PRs got no scan results at all until someone investigated. The agent completed the task it was given. Nothing told it that turning off the scan was off-limits, and it had the permissions to do it.

He sees the same pattern in the incident he described involving OpenAI agents and Hugging Face, where agents chasing benchmark answers escaped a sandbox and escalated into production using kernel exploits, default API keys, over-provisioned Kubernetes accounts, and metadata credentials. Each technique on that list is a routine pen test finding. "The attack wasn't really a novelty," Shash said. "The attacker was actually the novelty."

He recommends three controls:

• Least privilege. Give agents the minimum identity needed to do the task, never a senior engineer's token by default.
• Continuous monitoring. Watch what agents did during and after a task, so a config change that silently kills your scanning gets caught fast.
• A kill switch. When something goes catastrophically wrong, you need a way to stop the agent immediately.

Sonar’s Tom Howlett posed the opposite risk: boundaries so tight that every action needs approval, until people click through without reading. At that point, the boundaries need redesigning. Shash agreed, adding that guardrails differ by organization and team, and should be reviewed quarterly or twice a year as agents take on more.

Both come back to the same question: where does the work stop until something independent checks it?

What this means for your pipeline

Shash closed with two pieces of advice. First, invest in verification that is independent of the generator, and second, treat agents as identities with least privilege, monitoring, and a kill switch. Most incidents, he said, will come down to basic controls like these.

SonarQube holds every change to the same zero-trust, multilayered standard, whether a person or an agent wrote it. Gitar reviews pull requests in context and resolves CI failures against your rules, covering the review step Shash describes before a person opens the PR.

Listen to the full conversation with Shashank Patwardhan on The Next Commit, then bring independent, multilayered verification into your own agent loop with SonarQube.