Outpacing Security: Why AI Coding Agents Need AI Vulnerability Triage

Tens of thousands of new vulnerabilities are published every year. Your security team has to evaluate each one, determine if it applies to your infrastructure, assess the risk, and prioritize fixes. Meanwhile, your engineering teams are shipping code at an accelerating pace thanks to AI-powered coding agents.

This mismatch is the problem Santiago Castiñeira saw firsthand, and it’s the reason he founded Maze.

The Problem That Started It All

Santiago’s journey to founding Maze began at his previous company, where he worked closely with the security team at a major US-based public tech company. They were building a data lake of cybersecurity data—vulnerability information, asset inventory, and more—to drive their internal vulnerability remediation processes.

On the surface, it seemed like they had the right approach. The security team was staffed with experienced security engineers. But there was a fundamental problem hiding beneath the surface: a massive data problem.

“These teams were generally heavy with security engineers,” Santiago explains, “but they had a fundamentally deep data problem.” The core question they couldn’t answer efficiently was simple but critical: Which vulnerabilities should we fix today? Which ones can wait? Which ones don’t even apply to us?

The company was highly regulated with strict compliance requirements, so they were doing their best to keep up. But Santiago noticed something crucial—there was missing context for their decision-making. The skills needed to solve this problem weren’t just security expertise; they needed data engineering, machine learning, and a fresh perspective on how to approach the problem entirely.

From Observation to Exploration

When Santiago’s previous startup pivoted away from this problem space, he decided to explore the idea more deeply. He talked with security professionals to validate what he was seeing. He already had some customer experience from his previous role, but he wanted to confirm that this wasn’t just one company’s problem—it was systemic.

The feedback was clear: every company he spoke with faced the same challenge. Even investors were excited about the problem, though Santiago notes there were already “a million companies doing this one thing.” Yet the fundamental issue remained broken.

What made Santiago’s perspective valuable was that he wasn’t coming from a pure security background. He was bringing outside thinking into a problem that security teams had been wrestling with for years.

Building the Team and Validating the Vision

Santiago found his co-founder, Harin Adrienne, and they spent weeks together validating the problem and understanding the scale of the opportunity. Once they confirmed they were onto something real, Santiago brought in two of his former direct reports—engineers he trusted completely—from his previous company.

With five people and just enough funding for two months of runway, they decided to go for it.

When it came to hiring, Santiago developed a clear philosophy: look for people with high energy, high intelligence, and high integrity.

“If you look for candidates that have high energy, they generally will not sit still,” he explains. “They will always want to do something and find a way forward. If they are highly intelligent, they will find really smart things to do that actually move the needle. And if they have high integrity, you know they are going to have very good judgment.”

This hiring philosophy paid off. The team they built developed a high degree of autonomy. Engineers found their own problems to solve, came up with the next projects to work on, and suggested improvements based on patterns they’d seen elsewhere. When you hire well, those suggestions tend to be gold.

The MVP: Building the Decision Engine

Given the team’s background in data and engineering, they knew what their MVP needed to do: bring more contextual data into vulnerability decisions.

The initial idea was straightforward but powerful: Can we bring together more data and connect it to vulnerabilities so teams can make better-informed decisions about which ones to handle first?

The timing was fortuitous. In mid-2024, the first versions of LLMs like Claude were emerging. While these models had limitations, Santiago’s team proved something transformational: large language models could understand configuration and metadata from AWS, code repositories, and other sources, then produce informed assessments of vulnerabilities.

From mid-June to November 2024, the team built the core engine—the decision-making algorithm that would rank vulnerabilities. This was the hardest part. They validated it with security engineers, hired consultants, and worked with design partners.

Then came another 6-8 months of work—while simultaneously growing the team—to build a full MVP that customers could actually use in production.

The Architecture: Thinking Big from the Start

One of the earliest and most important decisions Santiago’s team made was determining which data sources to use. They could have pulled from 20 different sources, but that would have made the problem impossibly complex.

Instead, they made a deliberate choice: focus purely on cloud context. They’d look at metadata about running environments and infrastructure configuration, but they wouldn’t dig into codebases or GitHub initially. This constraint simplified the problem dramatically without losing critical functionality.

This decision-making approach—being intentional about what not to build—is something founders often overlook. Santiago’s team understood that constraints breed clarity.

Scaling From Day One

Because they were building for security teams at large enterprises, Santiago’s team knew from the beginning they needed to handle massive scale. They envisioned serving customers with tens of millions of open issues at any given time.

This meant building a horizontally scalable data pipeline from day one. They couldn’t collect data on-demand as agents ran because they’d hit API rate limits immediately. Instead, they built systems to ingest and process massive amounts of security data continuously.

This architectural decision shaped everything about how Maze was built.

The Roadmap: Listening to Design Partners

How do you decide what to build next when you’re solving a complex problem in a mature market? Santiago’s answer: talk obsessively with your design partners.

The roadmap came from a combination of their initial vision and continuous feedback from customers about what would give them the most value. Rather than imposing their ideas about how security management should work, they let customer conversations guide their priorities.

Why This Moment Matters

The convergence of two trends makes Maze’s timing perfect. First, security teams are overwhelmed by the volume of vulnerabilities they need to manage. Second, AI-powered coding agents are shipping code faster than ever, creating even more security surface area.

The solution isn’t hiring more security engineers—it’s building intelligent agents that can evaluate and prioritize vulnerabilities like a senior security engineer would, but at scale and speed that humans simply can’t match.

Santiago and the team at Maze are building exactly that.

Want to hear Santiago’s full story about building Maze, the specific technology decisions they made, and how they’re approaching the future of AI-driven security? Listen to the full episode of Code Story to dive deeper into how they’re eliminating vulnerability backlogs and changing the way companies approach security at scale.