AI Agents for Dependabot Alerts Need New SLAs

An agent can prepare the patch. Your queue still has to decide what matters.#

A Dependabot alert used to become an engineering task. Now an agent can receive the advisory metadata, dependency usage, and repository code, then investigate the issue and prepare a fix before anyone opens a ticket. The hard decision is no longer whether it can write the patch. It is which alerts deserve an emergency path, a normal review, or no automated remediation at all.

AI vulnerability triage creates different kinds of work#

A critical issue in a package used by a production service is not the same as a medium-severity issue in an unused development dependency. Neither is the same as a transitive dependency that is present but never reached by your code. The source reports that an agent can work from a specific vulnerability object. That includes the advisory, dependency usage, and repository code.

That matters because the agent has enough context to investigate a real alert. It does not have to start with a vague instruction like, “Check our security backlog.” But better investigation does not make every alert equally urgent. A production-facing dependency may need immediate review from the person accountable for that service. An unused dependency may need a recorded finding and a planned update. A package with no reachable path may need an exception with an owner and an expiry date.

Your alerts may all arrive in one queue. They should not all follow one path.

Dependabot alert automation exposes the real bottleneck#

Most security teams do not have a patch-writing problem. They have a decision problem. Who decides whether the dependency is actually used? Who checks that the upgrade does not break the service? Who can accept the risk when the patch cannot ship today? Who is allowed to merge a change that affects production code? When an agent investigates every alert quickly, those unanswered questions become visible fast. The queue fills with better pull requests. It does not automatically become safer. A team can mistake activity for progress here.

Twenty agent-prepared fixes may look like a healthier security process. If nobody knows which ones can merge, who must review them, or what happens when tests fail, the team has only moved the bottleneck. It has also made it harder to see.

Build risk classes before agentic security remediation#

Our recommendation is simple. Split the Dependabot queue into risk classes before you assign alerts to an agent. Use the facts that change the decision:

• Severity of the vulnerability
• Whether your code can reach the affected dependency
• Whether the dependency runs in production
• Whether the fix changes application behavior
• Whether a tested upgrade path exists

Then give each class its own operating rule. For every class, define four things.

Required evidence.
The agent should show why the alert belongs in that class. That might include where the dependency is used, whether the affected code path is reachable, the proposed version change, and test results.

Review owner.
Name the person or team who must assess the change. “Engineering” is not an owner.

Merge authority.
Decide who can merge the pull request. Low-risk updates may follow an existing code-owner path. Higher-risk fixes may require the service owner and security owner to approve. This is the same gap that appears when decision rights are missing from an agent workflow.

Resolution time.
Set the time allowed to patch, mitigate, or record an exception. An SLA without an exception path turns into quiet noncompliance.

A safer path for each alert#

Low-risk dependency updates can be a good place for agent preparation. The agent can investigate the alert, update the dependency, run the agreed checks, and open a pull request with the evidence a reviewer needs. That is bounded work. High-risk alerts need a different handoff. The agent can still gather the advisory details, identify affected repositories, show where the dependency is used, and prepare a proposed change. A named security or engineering owner should decide the urgency and approve the merge path.

Some alerts should not create a patch at all.

If a dependency is unreachable, unused, or accepted temporarily as a known risk, the agent should record the evidence and route the exception to its owner. That owner needs to be explicit, because an exception still needs someone responsible after the agent finds it.

Do not let an agent turn every finding into a pull request just because it can. That creates review work without improving the decision behind it.

The queue needs rules before it needs speed#

An agent can shorten the time between alert and proposed fix. It cannot decide what deserves urgency. That decision belongs in the queue design: risk class, required evidence, review ownership, merge rights, and a clear deadline for patching or accepting risk.

---

Acrein Group can build this into the remediation flow itself, so an agent prepares the right evidence and each Dependabot alert reaches the person who can actually decide what happens next.