How We Use an AI Agent to Handle Vanta Vulnerabilities Faster

Key Points:

• The deadline is the problem. We commit to fixing critical vulnerabilities within 10 days as part of our SOC 2 work, and Vanta tracks due dates for the other severities. One recent check surfaced 55 open vulnerabilities to review.
• The work was mostly sorting. Many alerts share a root cause, and some are already fixed in code but not yet deployed. Working that out by hand took the interrupt-duty engineer a few hours every week.
• A scheduled agent now does the first pass. It reads open findings from Vanta, ranks them by deadline, maps them to code, prepares and tests fixes where it can, and posts a short status in Slack.
• It proposes, people decide. The agent only opens draft merge requests for fixes it has verified. Its instructions forbid merging, releasing, force-pushing, or touching a default branch, and it only reads from Vanta.
• It is a pilot. We are still measuring time saved and learning which fixes the agent can handle reliably.

An AI agent now goes through our open vulnerability findings on a schedule. It works out which ones are close to their deadline, finds where they live in our code, prepares fixes for the ones it can verify, and leaves an engineer a short report with draft merge requests to review.

We built it because vulnerability triage was eating hours of our week, and the deadlines behind it are ones we have committed to. This post covers why that work was hard to keep up with, how the agent works, why we run it on Qovery Agent Tasks, and what we have not learned yet.

The alerts come with a deadline

As part of our SOC 2 commitments, we fix critical vulnerabilities within 10 days. Other severities have their own due dates, which we track in Vanta. Vanta lists the vulnerabilities found across our systems and attaches a due date to each one.

That sounds manageable until you look at the queue. One recent check surfaced 55 open vulnerabilities to review. For each of them, someone has to:

1. Find which part of the product is affected.
2. Check whether a fix exists.
3. Make the change and test it.
4. Keep an eye on the deadline.

Most of the time goes into the first two steps, and a lot of it turns out to be wasted. Several alerts often point to the same root cause. Other alerts describe a problem we already fixed in code but have not deployed yet, so the scanner still sees the old version. Telling those apart from the findings that need real work is slow and repetitive.

This work lands on the engineer on interrupt duty. They spent a few hours every week on it, on top of handling incidents and support requests. That is the worst place for careful, detail-heavy work: it gets done in fragments, between pages, and a deadline can slip without anyone deciding to let it slip.

Running it as a scheduled job

We did not want an assistant someone has to remember to ask. The deadlines arrive whether anyone is paying attention or not, so the triage runs on a schedule too.

The agent is a scheduled task. We are still working out the right cadence for security findings, which can become urgent between runs.

It connects to three kinds of systems:

• Vanta, through Vanta's MCP server, to read open findings and their due dates.
• Our source repositories, 16 of them, spread across GitHub and GitLab. It inspects both application dependencies and operating system or base image dependencies, because a finding can come from either.
• Slack, where it posts its status.

How the agent works

Each run goes through four stages.

1. Read

The agent pulls every open vulnerability from Vanta, with its severity and due date. Its instructions limit it to reading from Vanta. It looks at findings and does not change them.

2. Prioritize

It sorts findings by deadline and severity into three groups:

• Urgent: overdue, or due in 5 calendar days or less. These need action now.
• Soon: due in 6 to 14 days. These should be planned soon.
• No emergency: nothing due in the next two weeks.

The cut-offs are simple on purpose. Anyone in the company should be able to read the report and know where we stand without knowing how the agent decides.

3. Fix

This is where most of the time used to go. For each finding, the agent maps the vulnerable package back to the repositories and files that pull it in. That step is meant to catch the duplicates (one root cause, many alerts) and the findings that are already fixed in code but not yet deployed.

When a fix exists, the agent prepares the change and tests it. Only if the fix is verified does it open a draft merge request or pull request. If it cannot verify a fix, it does not open one. We would rather get no merge request than a speculative one that someone has to debug.

4. Report

The agent posts two short status messages in Slack. The report answers three questions:

• What is the current status? Is anything urgent?
• Which fixes are waiting for review?
• Which items need a human decision?

The goal is a report anyone can read in about 30 seconds.

One run's Slack report showed 21 vulnerabilities marked fixed, including work still waiting for redeployment, alongside pull requests awaiting validation. This is a snapshot of one run, not a measure of overall time saved or vulnerabilities resolved in production.

Taking over dependency update pull requests

Renovate and Dependabot are useful for finding outdated or vulnerable packages and proposing dependency updates. But updating a package manifest is only one part of resolving a finding. We may also need to change code that depends on the old behavior, run checks that cover the affected paths, and verify that the fix addresses the vulnerability.

Our agent can take over an existing Renovate or Dependabot pull request, investigate any required code changes, apply them, run relevant checks, and prepare the work for an engineer to review. This lets us continue from the dependency update through the surrounding development work, while keeping approval with a person.

Guardrails: the agent proposes, engineers decide

An agent that can propose changes across 16 repositories needs clear limits. These are written into the agent's instructions:

• It only reads from Vanta.
• It never changes a default branch.
• It never force-pushes, merges, or creates a release.
• It never opens a speculative or unverified fix.
• People validate every change and make every decision.

In practice, the agent's job ends at a draft merge request on a separate branch. An engineer reviews it, approves it, and merges it through our normal process. GitHub and GitLab branch protection rules also prevent direct pushes to the production branch, so changes must go through those controls before they can ship.

This is also meant to change the interrupt-duty engineer's job. Instead of starting from a raw list of alerts, the goal is that they start from a sorted list, draft fixes that already pass tests, and a short list of items the agent flagged as needing human judgment.

Why we run it on Qovery Agent Tasks

We built the agent on Qovery Agent Tasks, a feature currently in beta. The Agent Tasks documentation explains how to configure and run them. It is our own product, so we had an obvious bias toward it. But a few of its properties fit this job well.

It is built for scheduled agents. Agent Tasks can run one time or on a schedule, and can be triggered by a webhook. We set the instructions, context, boundaries, and trigger, and the job runs on a schedule.

It runs on infrastructure you control. According to the Agent Tasks announcement, tasks run on your own infrastructure with network egress rules. That fits an agent that reads security findings and proposes changes to source code.

Credentials and tools are managed in one place. We configure the MCP servers and secrets the task needs in Qovery. That gives it access to Vanta, our Git providers, and Slack without depending on an engineer's personal machine.

The environment is customizable. Agent Tasks also support custom environments, which fits a job that has to test each fix before proposing it.

Where we are, and what we still have to learn

This is a pilot. The Slack report gives us a view of one run, but we have not yet measured time saved or how many prepared changes have made it through review and deployment.

Here is what we plan to do next:

1. Find the right schedule for the agent as we learn how quickly findings need attention.
2. Measure the time saved and learn which kinds of fixes it can handle reliably.
3. Handle more kinds of fixes and move from pilot to standard practice if the results support it.

The split we want to keep as it grows: the agent does the sorting and the first draft, and engineers review, decide, and ship.