Why we tackled the hard problem first: triage & investigation
We built Maze's investigation agents before we built remediation agents, and we did it on purpose.
Most security vendors in this space rush to ship a "fix it" button, but fixing vulnerabilities that don't pose a real threat isn't progress. So we started by getting teams out of the noise.
Our AI agents investigate every vulnerability in your environment, checking whether the technical requirements for exploitation are actually present in your specific infrastructure. On average, 80-90% of vulnerabilities are not exploitable.
Those investigation agents are running in production across customers worldwide, and now we're ready for the next step. Fixing them.
Our understanding of the vulnerabilities is what makes our remediation different. AI-powered remediation is nothing new; it's just never really worked. We'll get into why it didn't work and share how we're taking a different approach below.
"I've asked vendors to build this for years, and this is the first time I've actually seen it done right." — James Berthoty, Analyst @ Latio Tech
What remediating a vulnerability looks like today
Before we get into how Maze handles remediation, let's walk through what this process looks like for most engineering teams today. This is a real example that we've since anonymized (and patched of course).
Your scanner flags CVE-2025-32989, a vulnerability in a package called gnutls. Your developer gets the ticket. First question: what is gnutls? They didn't install it. They've never touched it. It's not in their code.
So the developer starts digging. Turns out gnutls is a security library that got pulled in as a dependency of wget, which was installed via the package manager in the container's build process. The developer didn't choose gnutls. They didn't choose wget, either. Both came along for the ride when the container image was built.
Getting to this point, depending on your current tooling and awareness, could have taken 15 minutes or a few hours.
Red Hat UBI 9 (base image)
└── microdnf install wget ← installed during the container build
└── gnutls 3.8.3 ← pulled in as a dependency of wget
this is what's vulnerableNow they found the issue, but the developer has to figure out the fix. Do they upgrade to a new version of Red Hat? Does a new version even exist? If it does, could it break the application? What if we just pin a specific version of gnutls? That adds maintenance overhead, but it could work. Can they just remove wget? Maybe, but what if something else depends on it?
Maybe they spend an hour and find a newer version of gnutls that patches the CVE. But now what? Do they pin that version? Will that cause conflicts with other packages? Has Red Hat even published it to their repos yet?
Every answer leads to another question, and the developer is still stuck researching instead of fixing.
This research takes hours. Multiply that by hundreds of vulnerabilities in the backlog, and you start to understand why security tickets get ignored.
Not because developers don't care, but because the work to figure out the right fix is exhausting and the "guidance" they're given doesn't help.
How the remediation process changes with Maze
Maze's investigation agents would first verify if the vulnerability was exploitable. If it was, then the remediation agents analyze the vulnerability, trace how it got there, and come back with verified fixes that work in your environment. Here's what that looks like for our gnutls example:
Rebuild the container image. Red Hat has already patched gnutls in their UBI 9 repositories. A fresh build pulls the fix automatically. No code changes. The agents verify this by checking that the rebuilt image includes gnutls-3.8.3-6.el9_6.2 or newer. Music to a developer's ears.
Remove wget entirely. If wget wasn't needed at runtime, remove it from the build, and gnutls goes with it. The agents, of course, flag the risk that this could break scripts or processes that depend on wget being available.
Each option includes the trade-offs. The agents recommend the simplest and most effective path.
In this case, a rebuild resolves it, and they've already confirmed this by checking the patched image. Two minutes instead of two hours.
Most remediation guidance doesn't actually help
This gnutls vulnerability we've been discussing isn't unusual. It's the norm. Remediating vulnerabilities can be hard work.
Most tools will tell you a vulnerability exists and determine if a newer version is available. Some will try to tell you which version to upgrade to. But they don't analyze whether that version introduces new risk or how much risk it introduces. They don't tell you how the vulnerable package got into your environment or whether you even control it directly.
Developers end up spending hours researching a fix that a tool should have figured out for them. Or worse, they fix the wrong thing, and the same vulnerability shows up again in the next weekly report.
When we built Maze's remediation agents, our engineering team built what they wished they'd had when they were on the other side of these tickets. They've been the developer staring at a list of vulnerability findings with zero context. That experience shaped everything about how Maze handles remediation.
How Maze thinks about fixes
Every vulnerability got into your environment through a specific path. It came from the base image, or it was installed in a build step, or it's a dependency of something your developer actually chose. The fix is different depending on the answer.
Our agents trace that path before they recommend anything. They research the available fixes, then verify that those fixes actually resolve the issue and don't create new problems.
Every environment is different
There is always the textbook fix, but there is never a perfect fix every single time. The ideal fix might require a major version upgrade that introduces breaking changes. It might need a change window that's a month away.
That's why Maze gives you options that make sense for the exact moment you're in. We tell you which option we recommend and why, but we give you all of them, because your environment is your environment, and none of our agents were on your standup.
We verify before we recommend
Before suggesting a fix, our agents confirm it actually resolves the vulnerability and flag if it introduces new ones. When we say "rebuild the image and the vulnerability is gone," we've already checked the patched image to make sure.
There's evidence and reasoning, no static rules, behind every recommendation.
You can't always patch, but you shouldn't be stuck
Not every vulnerability has a patch ready to go. Maybe the open-source maintainer hasn't shipped one yet. Maybe the fix requires a major version upgrade that needs months of testing, or the change window is weeks away and the vulnerability is exploitable today.
Our investigation agents already know what conditions need to be true for a vulnerability to be exploited. That means our remediation agents can identify changes that break those conditions: it could be a configuration change, a WAF rule update, or a security group adjustment. We tell you exactly what to change and why it makes the vulnerability not exploitable while you work on the permanent fix.
You stop the bleeding first. Then you remediate on your own timeline.
But who should fix it?
Finding the right person or team to own a fix is often harder than finding the fix itself.
The engineer who built the application moved on. The tags in your cloud environment are outdated. The person who owns the infrastructure might not be the person who owns the code that introduced the vulnerability.
Maze analyzes historical data from your repositories and cloud environment to figure out who should actually own a specific fix. Because any single data source is likely outdated, we combine multiple signals to route with much higher confidence, so fixes land with the right people the first time, with all the context they need.
One fix, many vulnerabilities
A single package update or base image rebuild can resolve dozens of vulnerabilities at once, but most tools have no way to show you that. They present every CVE as an individual problem, and your team ends up fixing them one by one, like they're unrelated. With Maze, no more whack-a-mole.
Maze surfaces these opportunities automatically. One base image upgrade becomes one ticket and one pull request instead of 50 separate items in your backlog.
When you plan your next sprint, you can come prepared with the one fix that will have the most impact on your security posture.
See it for yourself
We started with investigation agents to help you focus your efforts. Now we've built remediation agents to help you fix what matters. Both give you more time back, all while matching your environment and routing to the right person every time.
Remediation that helps you close the ticket faster than ever, not another notification left to die alone in your ticketing system.
That's remediation developers will actually use.
Book a demo and be one of the first to see it.