In this episode, I sit down with Igor Andriushchenko, Head of Security and CISO at Lovable, to discuss securing AI-native development, including soft guardrails versus hard boundaries, the shared responsibility model for vibe coding platforms, and how GRC engineering fits into a world of AI-powered attackers.
I had been chasing Igor down on LinkedIn since February, so I was glad to finally get him on the show. Lovable sits in an unusual spot. Igor has to run security for a company that went from roughly 40 people to 400 laptops in MDM inside a year, and at the same time the product he is securing hands software creation to people who are not developers and have never thought about security at all. Those two problems pull in different directions, and the conversation gets into how his team handles both.
We chatted about:
Building a security program for a 15x company when you already know you are going to be 10x, and what breaks along the way
Soft guardrails versus hard guardrails, why hard blocks get routed around by AI-assisted workflows, and how to tell which problems deserve which
Anchoring guardrail decisions in business goals, risks, and threats instead of tool defaults
The gap between democratized development and democratized security, and what a platform owes the 99 percent
Lovable’s auto-fix toggle, the per-app threat model built behind the scenes, and the goal of shipping an app with no security tab at all
Whether frontier models will ever produce secure code by default, and why defense in depth still does most of the work
Governing the reality that every employee vibe coding an app starts to look like a new vendor
GRC engineering as the discipline for measuring control efficiency layer by layer
CRA, NIS2, and the EU AI Act landing on citizen developers who never considered themselves software manufacturers
Prefer to listen?
Please be sure to leave a rating and review, as it truly helps the show!
Takeaways
Build the security program for the company you are about to be
Igor joined Lovable as the first security hire when it was around 40 people. Today his team is 20 plus and covers product security, GRC, IT, and platform safety, and the company is managing about 400 laptops in MDM. He described the security team itself as growing roughly 25x in that stretch, from one person to around 25 with offers out.
What I found useful was how he framed the planning problem. He and the team could see the revenue numbers before anyone else could, which meant they could see the trajectory. “As a CISO you just need to build your security program to cater for probably 15x company. If you expect to be 10x, if you add extra on top for extra resilience, then you’ll be fine.” He also made the point that the threat model changes as you scale, because a 40 person company and a company on the front page of every tech publication do not attract the same adversaries. That is a very different exercise than budgeting off last year’s headcount, and it is one most security leaders in high growth environments should be doing more deliberately.
Soft guardrails are coming for most of your controls, but not all of them
Igor’s argument is that deterministic controls were an artifact of a deterministic world. Static analysis was called static for a reason. Rules matched or they did not. What AI enables is a control that can look at intent, at a person’s role, at what they are actually trying to accomplish, and make a judgment. He compared it to onboarding an intern and sitting next to them, which is a much better analogy for adaptive policy than anything I have heard from a vendor.
He is not arguing hard blocks go away. He explicitly wants some. “We take human creativity and we multiply it by agent creativity,” and sometimes the result is an agent with no judgment about what it should never do. His example of a genuine hard boundary is an agent never escaping a sandbox, or never being handed a powerful admin-level CLI with developer credentials. The part that matters for practitioners is that he derives those hard boundaries from business risk rather than from a tool’s default policy set. If your risk model is done deeply enough, the things that should never happen are already written down somewhere.
The platform owes the 99 percent more than a fix button
This was the thread I came in most curious about. Lovable’s stated goal is empowering the 99 percent to build, and I have made the argument for a while that we democratized development without democratizing security. Igor’s answer is that they tried the obvious thing first and it did not work. They surfaced security bugs in a project with a button to have AI fix it, and very few people clicked it. Their research found two reasons. People were scared of breaking something that already worked, and security felt complicated and unfamiliar.
So they pushed the responsibility further onto the platform. In June they shipped an auto-fix toggle in settings, and behind the scenes every application gets scanned and a security model built for it, which is functionally a threat model. The direction he described is a platform that fixes the obvious issues silently and reserves the human interaction for questions only the builder can answer, like whether a given table should be private or public. “Ideally, there should be no security tab whatsoever in the app.” That is secure by design applied to an audience that will never read a secure coding guide, and it is only possible because Lovable owns the whole loop from generation to deployment to runtime. Most vendors cannot make that claim, which is exactly why platform providers have systemic leverage that individual security teams do not.
Good enough changed, and that is what makes GRC engineering interesting
Igor’s take on AI-powered attackers is the part of this conversation I keep thinking about. Defense in depth historically worked on a good enough standard. You layered controls, accepted that each layer had gaps, and trusted that the aggregate would slow an attacker down long enough to detect and eject them. His argument is that standard no longer holds when someone with no offensive security background can point a capable model at a target and let it work. As he put it, that is “hacking at the cost of electricity.” A relentless attacker will find the gap in layer one, then the gap in layer two, and it will do it fast.
His conclusion is that each layer now needs measured, near-complete coverage rather than good enough coverage. If you have MFA and EDR, they need to be everywhere, not on most employees and not on that one contractor group. And measuring control efficiency layer by layer is a GRC problem, because GRC already holds the risks, the vendors, the controls, and the mapping between them. Build the eval, or the KPI if you prefer the old word, get coverage from 80 to 85 to 90, and keep going. I have spent years pushing back on the compliance does not equal security line, and this is a good articulation of why. Used this way, GRC is how you prove your controls actually work in near real time rather than how you generate a report.
Regulation is coming for people who do not know they are software manufacturers
The last thread was one I did not expect to get a fully formed answer on. When a citizen developer ships an app that touches PII or PHI, they have produced software and put it into the world, even though nobody would call them a vendor. Igor’s view is that the platform’s job is to make the obligations visible early, before someone publishes. Lovable already draws some hard lines, and he mentioned taking down apps in regulated spaces where they needed to see evidence of a license first. The vision he laid out goes further, with the platform telling a builder up front what publishing will require of them, and pointing them at where to go get it.
He also mentioned a recently released opt-in trust center for apps built on the platform, which generates a compliance posture page automatically from the app and its data. That is GRC engineering aimed at customer apps rather than at the platform’s own audit, and it is a genuinely interesting model for reducing regulatory overhead on people who never signed up to carry it. As Igor put it, the shared responsibility does not sit only with the platform. The moment a builder starts putting real people’s data into what they built, things change quickly for what they need to comply with.
Igor closed with something worth repeating for anyone in this space. If one vibe coding platform fails badly, every other platform gets the same questions the next morning. The whole category is judged together, which is a decent argument for building the security bar high early rather than after the first bad headline.
You can follow Igor on LinkedIn at https://www.linkedin.com/in/igor-andriushchenko and find Lovable at https://lovable.dev
