A few days ago I made the case that the security industry has quietly flipped its hardest problem. For most of its history, finding vulnerabilities was the expensive part: skilled people, months of work. AI ended that. Frontier models now find flaws at machine speed, and the bottleneck has moved to fixing them. Testimony to Congress put a number on it: of 1,500 vulnerabilities one frontier model surfaced, only 6% have been patched.
That post raised a question it didn't answer. If the old operating model is breaking, what does the team that actually keeps up look like?
So this week I put it to Raj Umadas. Raj has built and led security at Etsy, Spotify, Squarespace, WeWork, and ActBlue, and now runs security at Underdog. He came on with a thesis that cuts against twenty years of instinct: security teams shouldn't be slowing AI adoption down. They should be leading it.
Here's what that actually means in practice.
YouTube · ReplayStop Slowing Down AI. Your Security Team Should Be Leading It.First, be honest about what changed
Midway through, Raj did something I wish more people would do. He stopped and said, in effect, let's not hide behind euphemisms. Everyone agrees "something changed." What actually changed?
Two things, and they compound.
The first is volume. We are shipping far more software, far faster, and the rate is still accelerating. The second is scrutiny. Code used to get written with a human's eyes on it. Now we are cranking out code that no person has actually read, written by a system that is, in Raj's words, not entirely reliable, not predictable, non-deterministic. He tells a story everyone who codes will recognize: he instructs the AI to never hard-code keys, commits the work, and Git immediately flags the keys it left in anyway.
Raj frames the whole thing as an N-times-N problem. The numerator got worse, because there is more code. The surface got bigger, because that code connects to more and more things. And the review got thinner, because fewer human eyes touch each line. All at once. He added the part most people skip: a human is flawed but at least well-intentioned, and you can sue a human. There is none of that backstop with a model.
Put it together and Raj makes a prediction worth writing down. When the next Verizon breach report lands, he expects phishing to start declining as the top entry point, with real application-security bugs and zero-day usage rising to take its place. For as long as anyone can remember, the number one way companies get breached has been a phished human. Raj thinks that is about to fall, because we are now generating the vulnerable surface ourselves, faster than ever. It's a testable claim. Watch the report.
The question every security leader has to answer
Once you accept that picture, Raj poses the question the entire conversation turns on. In a world that looks like this, can you solve these problems without using AI?
Not "do you like AI." Not "is AI safe." Can your existing staffing, your existing training, your existing tooling, your existing playbooks keep pace with more software, shipped faster, with less human review, by a non-deterministic author?
His answer was flat. He could not think of a way to support a world like this with the old methodologies. He can only support it by leveraging AI well. That is the move that reframes everything. AI is not only the source of the risk. It is also the only thing that lets a human-paced security team operate at machine speed. Both halves of the coin at once.
Builders first, default to yes
This is where Raj's background matters. The teams he came up on, at Etsy, Spotify, and Squarespace, never saw themselves as an advisory function handing down opinions about systems they didn't deeply understand. They considered themselves builders first and security engineers second. Their job was to get their hands in and unblock the people building the business.
So when AI arrived, his instinct wasn't to gatekeep. It was to get ahead of the business. At ActBlue, before anyone asked, his team requested the budget and the mandate to put AI tools in their own hands and run side projects, purely to build expertise. Roughly two months later the requests started coming in from engineering. By then his team could speak to leadership from a place of actually knowing the technology. They had been talking about RAG before it was common, about MCP before MCP existed as a thing. When the business showed up, the answer wasn't a nervous no. It was: we know RAG, we know MCP, we know vibe coding, and here is how we get to a yes.
That phrase is the whole philosophy. You don't default to no because you don't understand something. You default to yes, even when getting there means figuring out how to make yes safe.
Raj pushed it onto a question the industry keeps fighting about: did AI democratize building? His take is no, and it's sharper than the usual answer. Everyone was always a builder. Go back to early humans specializing, and people have always built and traded value. The marketing person wiring up a spreadsheet with one API key was building. We just slapped the label "shadow IT" on it and got scared, because they were building outside our control. AI didn't create builders. It handed the builders who were already there much more powerful tools. The job isn't to stop them. It's to bring everyone into the same guarded space and make the power safe, the way you'd codify "127.0.0.1 isn't reachable from the internet" into the platform so a marketer never has to be told.
How you actually do it
Philosophy is cheap. The part of this conversation that separates it from every other "AI is changing security" think-piece is the mechanics.
Track a learning number, not a productivity number. For the first couple of months, Raj's team didn't measure productivity and try to drive it up. They measured learning and drove that up: have we explored this concept, have we applied it to a real problem. The efficiency gains showed up anyway, as a side effect. Detection tuning got faster, infrastructure-as-code spread through the program, the team could cross-train and explain themselves to auditors more easily. But efficiency was never the target. A team that understood the tools deeply enough to make good calls was the target.
Make the right thing the easiest thing to do. This came in via a comment from Darren Szalkowski, who ran product security at Ford for years and described it as his whole mission. Raj endorsed it completely. Guardrails and golden paths work because if the safe path is also the path of least resistance, people walk it on their own. The catch: it takes creativity, not a copied checklist. It is easy to feel bad that developers don't bring you their sensitive work. It is harder, and far more effective, to hook into their workflow and offer security services compelling enough that they'd choose you in an open market.
Replace the annual ritual with continuous testing. Raj's line on this was blunt: pen tests that happen once a year? Give me a break. You can run continuous red teaming right now, enhanced by AI. The cadence of defense has to match the cadence of shipping.
Build on an auditable backbone. Raj prefers the word "leverage" to "rely" for a reason. You put the non-deterministic part inside a deterministic, auditable structure. His team codifies configurations as infrastructure-as-code and wraps tools in regular, auditable APIs and pipelines. The runtime, the APIs, the configs are all normal software you can lock down, monitor, and review, which is how you get AI's leverage without blindly trusting it.
And the part that makes this harder than developer adoption: you are defending in a hostile environment. A security team using AI tools, supporting an organization, has to assume attackers are targeting those same tools. The answer is not to avoid them. It's to assume failure, think chaos-monkey, and build to be resilient to it.
Running under all of it is one habit: share the work. Raj's team commits to demo days. If you're going to spend company time learning, you give back by presenting what you found, and that is how you build the trust that earns you the next yes.
The takeaway
The find/fix gap, that 6%, does not close by hiring more humans to patch faster. It closes when security teams rebuild around AI: finding their own flaws first, prioritizing their own backlog, remediating at machine speed before anyone outside has to. And that rebuild starts with a posture change, not a tool purchase. Stop slowing AI down. Start leading it. Builders first. Default to yes.