The Ultimate Shift Left: Embedding Security Into The AI That Writes Your Code

The distance between having a business problem and shipping software used to be measured in engineering headcount and months of work. Now, it's an afternoon and a prompt. Someone in legal, marketing, or finance can describe what they need, watch an AI assistant assemble a working application, and put it in front of colleagues before lunch. The catch sits in what that application carries: embedded credentials, standing permissions, and connections to systems of record that no security team ever reviewed. Speed like that is a real productivity gain, and it's also a new and fast-multiplying way for an enterprise to get breached.

On the latest episode of The Data Wire's Beyond the IT Headlines podcast, Dr. Ratinder Paul Singh Ahuja laid out what that shift demands of security teams. Ahuja is Chief Technology Officer and Vice President for Security and Networking at Everpure, a serial security entrepreneur who has founded four companies and holds more than 70 patents. His argument starts from a premise most enterprises haven't caught up to: the age of the citizen developer has already arrived, and the security model built for professional engineers doesn't stretch to cover it.

"This is the ultimate shift left. A team of five security engineers can't review code generated by thousands of citizen developers, so the standards have to be enforced programmatically, before anything ships," Ahuja said.

When anyone can ship an app, the attack surface follows

He doesn't treat any of this as a coming trend. It's already ordinary. "The age of the citizen developer is here. Anyone with an idea can use available tools to build applications." He offered a close-to-home example: a colleague on Everpure's legal team who turned a complex audit process into an automation using Claude Code, no engineering background required. That's the upside working as intended. The trouble starts when the same person hosts the result on a platform like Replit and takes it live without passing through any of the gates a secure software development lifecycle would normally impose: threat modeling, scanning for embedded secrets, sanctioned access to systems like Salesforce, penetration testing, and hardened deployment. "If you're building a small prototype to share a concept, that's fine," Ahuja said. "But as you take real business processes dealing with restricted data and want to use them widely, you need governed processes around a formal secure software development lifecycle." On platforms where users spin up new applications a day by the tens of thousands, only a fraction are enterprise-relevant, but his arithmetic is still sobering. A thousand a day is 365,000 a year, many of them wired into corporate data and running outside any governance process.

The exposure compounds because this code doesn't stay put. Citizen developers publish snippets and whole projects to public repositories, where other builders download and reuse them. "It creates a worm effect that continues to fan out with a broader impact," Ahuja said. Speed makes an old failure mode worse. "People will build an app, embed the data file directly inside the application, and hardcode the secrets to connect the two right into the code," he said. Assistants have grown savvier about catching this, he noted, but the human stays in charge of ignoring them. "Claude's gotten a bit smarter about it, it'll try to mask secrets, but if you override it and say just hardcode it, it will," Ahuja said. "And most people don't even read the security alerts. They just click accept on everything."

The permissions problem runs deeper than leaked keys. As enterprises move from building apps to deploying agents and agent swarms, those agents act directly on live data with administrative access and automated authority granted without much human thought. Every new connector, skill, and integration widens the ground they defend. The waste can pile up even without an adversary. "Badly written code can create infinite loops that call business systems, exhaust API tokens, or rack up $20,000 in unexpected cloud consumption," Ahuja said. The common thread, he added, is that nobody stops to ask where the data actually goes.

If a security team can't review this volume of code by hand, the obvious responses are to abandon review or to slow everything down. Ahuja rejects both. His answer is to stop treating security as a stage that code reaches after it's written, and to build it into the tools doing the writing instead. That reframing is where his central idea lives.

Security moves inside the coding tool, not the deployment gate

Professional security has long had disciplined methods for this. Teams use structured frameworks to harden code against spoofing, tampering, and privilege escalation before it ships. What citizen developers lack, Ahuja argued, is any of that discipline, because a plain-language prompt almost never instructs the model to follow rigorous security standards. His fix is to move the discipline into the tool. "I built a fully governed development system that wraps around coding harnesses like Claude Code, Cursor, or Codex," he said. "It programmatically enforces the secure software development lifecycle without relying on the user to request it." In practice, the system performs threat modeling, writes security tests, and sets up least-privilege access as the code is generated, folding standards like industry hardening benchmarks directly into the tool.

"This is the ultimate shift left," said Ahuja. "By embedding security standards like CIS benchmarks directly into the AI harness, security is enforced programmatically before deployment." Rather than letting developers build unhardened code and throw it over a fence to deployment engineers, the standards live in the harness itself. The piece that makes this trustworthy is what he calls a mechanical checker, a deterministic validator, not another AI, that sits between the coding agent and production. "It acts like an automated program manager with a checklist, refusing to let code pass to the next stage until every security requirement is validated." It exists because the coding agents can't be taken at their word. "You ask for ten things, they say all ten are done. What's the proof? You check, and only five are done."

The checker's proof is concrete rather than declarative. "It requires positive and negative testing proof, for example, intentionally stripping out a security patch to verify that the test fails," Ahuja said. Every validated output is signed and timestamped, which he described as "a verifiable, auditable, and provably correct deployment outcome with a complete audit trail," rather than ten thousand lines of code nobody fully understands. He's candid that natural language alone won't get there. "You need a method to precisely capture your intent, not just 'I want a dashboard,' but a mathematically precise definition of that dashboard, so the coding agent can be verified against it," he said. "Natural language is open to interpretation, even between two humans, let alone a machine."

The risk this contains is not hypothetical. Ahuja recounted an incident he traced to an AI system's test run that got loose. "It scanned 9,000 public-facing web apps, broke into some of them, and created a malicious Python package," the kind of AI-orchestrated attack that turns an organization's own tooling against it. The irony he drew out was that a security company that scans packages for a living then pulled that same malicious package into its own environment. Part of what makes these attacks land, he added, is that few teams actually know what they've connected. "Do you actually know what data access you've granted to that app, skill, or connector in your toolchain?" he asked.

Building security into the harness handles the code an enterprise creates from here on. It says nothing about the systems already running, already connected, and, by Ahuja's reckoning, already compromised. For everything downstream of the coding tool, he leans on a different principle, one that assumes the worst has happened and plans around it.

Assume the breach, then contain what an intruder can reach

"There are two kinds of enterprises. Those that have been breached, and those that don't know they've been breached yet." Treat everything as already compromised, he argued, and prevention alone stops looking like a strategy. "Detection and protection alone are futile because breaches happen 99.9% of the time due to simple mistakes." What follows is zero trust and least privilege. "Once two parties authenticate, they're authorized to talk about exactly one approved topic, nothing more," Ahuja said. If that identity is later spoofed, the intruder still can't pivot elsewhere, because it was never permitted to reach those systems in the first place. The damage stays boxed into a narrow, defined lane.

These ideas aren't new, and that's Ahuja's point about why they went unrealized. Enforcing least-privilege access was nearly impossible to implement at scale by hand. AI changes the economics. "Now AI can be used to discover the right policy and generate the least-privilege policy templates automatically," he said, which is what moves zero trust into a practical modernization step rather than a standing aspiration.

Ahuja pairs containment with the assumption that recovery will be needed. Detection that fails silently isn't a plan, which is why security leaders have been shifting toward resilient data and provable recovery instead of prevention alone, and toward treating recovery as more than a disaster-recovery checkbox. The two halves reinforce each other: least privilege limits how far an incident spreads, and provable recovery gives the organization a way back from the incidents that get through.

The outlook isn't purely grim. "Security has historically been asymmetric," Ahuja said. "Threat actors focus entirely on attacks, while thin internal teams defend vast enterprise assets. AI magnifies threat actors' capabilities by 10x." But those same capabilities can be aimed the other way, he said. "Leveraging these same AI capabilities and extreme shift-left methodologies levels the playing field. It gives defenders the same scale and intelligence to match the threat landscape."