Manoj, with your remit spanning technology, innovation, and emerging threats, how do you distinguish a security trend worth investing in from one that is simply industry noise?
The difference is whether the trend creates a measurable change in risk, and whether customers are already feeling it. AI security has already crossed that threshold. In a short period, I’ve spoken with more than 100 C-level leaders, and the questions have shifted from “What might AI mean for security?” to “What do we need to do now?” A trend becomes worth investing in when three things connect: a real change in the threat model, evidence that customers are experiencing it, and a practical security problem that technology can actually help solve. Autonomous attackers and agentic software development meet all three tests.
AI agents are now writing code while adversaries are using AI to find and exploit weaknesses. What has become harder about building security controls that can keep pace with machine speed?
The biggest change is that both sides of the equation are accelerating. Organizations can ship more code with AI, but more code also means more vulnerabilities. At the same time, attackers have agents that can work continuously to search through vulnerability backlogs to chain, or link weaknesses together, and pursue attack paths that previously would have taken more time or effort than humans might want to invest in it. That breaks a security model built around humans manually reviewing every decision. Humans still matter tremendously, but the human aspect needs to be on the loop rather than in the loop. The challenge is building security loops that are fast enough to keep pace with AI without giving autonomous systems unlimited freedom. Security teams are not trying to block AI; they are trying to keep companies from confusing speed with safety. It’s a balancing act.
As security tools and controls proliferate, how do you prevent your own security architecture from becoming overly complex, particularly when new capabilities have to fit into existing developer and engineering workflows?
What you absolutely can’t do is add another layer of tooling every time a new risk appears. Security has to become part of the way software is built and operated. In an agentic environment, that means thinking across the entire development supply chain and applying best practices for discovery, policy, testing, and governance across those layers. The goal should be to reduce the number of places where developers need to make a separate security decision. And controls must appear inside existing workflows to give developers or agents a clear path to remediation. At the architecture level, I think simplicity comes from having a consistent security loop: discover what is being used, understand the risk, enforce policy, test continuously, and secure agentic code from the moment it's created, not just after it's been in use.
You’ve brought research, developer advocacy, field engineering, AI partnerships, and product engineering under one technical organization. Where does friction typically arise when these functions have to execute against one security and technology strategy?
Friction usually appears when different teams are looking at the same problem from different horizons. What I mean is that researchers may see a new class of risk before customers fully recognize it. The important thing is turning those different perspectives into a feedback loop rather than allowing them to become competing priorities. We’ve seen that recently with agentic security research: Research into areas such as MCP servers exposed new classes of risk, customers reacted quickly, and that signal helped inform product capabilities designed to address those problems. A strong technical organization should be able to move information in both directions: research informing product and strategy, while customer and developer experience keeps research grounded in problems that actually matter.
When evaluating a cybersecurity technology for Snyk, what evidence matters beyond a successful PoC, particularly around integration, reliability, scale, and real-world developer adoption?
A PoC can show that something works under controlled conditions. The harder question is whether that PoC still works when you put it into a real engineering organization. We need to understand whether the technology can operate continuously, and at the pace and scale with which modern software is being created. That last point is becoming especially important in an AI-driven development environment. If an organization moves from producing two times as much code to 10 or even 100 times as much code, the security capability that relies on proportional increases in manual work simply will not scale. In short, adoption matters as much as detection. A technology can identify every possible problem, but if developers ignore it because it creates too much friction or too much noise, it hasn't fixed anything. The standard should be whether the capability can become part of a repeatable security loop that helps teams find, validate, and remediate risk at the speed the organization actually operates.
Snyk has pushed security closer to where software is built. As AI becomes an active participant in software development, which assumptions about developer security do you think the industry needs to rethink?
The biggest assumption we need to rethink is that the developer is always the primary actor creating software. Increasingly, as AI agents become more sophisticated, they may be not only writing the code and selecting dependencies, but invoking tools, connecting to MCP servers, and making decisions across an entire development workflow. That creates a new software supply chain with components that traditional developer security models were not designed to govern. It also changes what a vulnerability can look like. Some of the most dangerous AI-era malware may not look like malware at all; it could be a few lines of natural language that persuade an agent to do something it shouldn't do. Security has to understand behavior, context, and intent in addition to traditional code patterns. We can't assume that the AI-generating software can also be the final authority on whether that software is secure. Put simply: The generator cannot be the validator. Organizations need independent validation, continuous testing, and clear policies around what agents are allowed to do. The developer remains critical, but developer security is becoming broader than protecting human-written code.
