Picture your Monday. The AppSec queue holds a long list of dependency vulnerabilities across a pile of repositories, and every fix means a developer stopping other work to review a pull request. Someone on your team says Snyk has an agent that can chew through the backlog. Before you say yes, you want to know what it actually does and whether the number in the announcement holds up.
Here is what the post reports. Snyk put its Evo Remediation Agent into Open Preview, and the change is in who starts the work. Until now the agent ran in a developer's CLI or ADE. Now you, on the AppSec side, define a campaign: which vulnerabilities, which repositories, what schedule. The agent works through them in a Snyk-hosted sandbox and opens pull requests. It checks itself with builds, available tests and rescans, and it "does not merge changes." The merge stays with a person.
Then comes the figure that will end up in your slide deck. Snyk reports a mergeable fix rate of 90.2% across 307 dependency-upgrade tasks, against 77.5% for Claude Code with Snyk findings and 59.6% for Claude Code alone, all on the same model. The post is plain that this number is Snyk's, from Snyk's own VulnBump benchmark, and it adds two labels you should carry with it. First, Snyk names the model as the constant without naming the model. Second, the 90.2% belongs to the "CLI-based Remediation Agent," the engine underneath, not to the campaign product being announced. The campaign version runs in a hosted sandbox on public package registries under a daily fix allowance. So if someone quotes you 90.2% for campaigns, that is not what was measured.
What holds up on its own is the definition. A fix counts only if dependencies resolve, the targeted vulnerabilities disappear on rescan, the application builds, and previously passing tests still pass. In Snyk's words, "A pull request that breaks the build, fails existing tests, or leaves the vulnerability in place adds review work and doesn't shrink the backlog." That is a better yardstick than fixes generated, and it is one you can put to any vendor selling a fix agent.
Now the turn, the part where the catalog looks at its own record. The catalog holds the ingredients and not the new thing. Snyk has 50 API pages. The Snyk Issues API carries the findings a campaign would target. The Snyk Orgs API matches the Organization the post scopes one to. The Snyk Pull Request Templates API sits on the output, and the Snyk MCP Server is the agent-facing door. But no page in the record is named for campaigns. For an Open Preview gated through the account team, that is not a failure, yet it means the feature exists today as a product rather than as a contract you can inspect. If you wanted to wire campaigns into your own tooling, there is nothing in the record to read first.
The measurement of Snyk itself is strong, with one hole in it. Snyk holds a Kin Score of 79.1, exemplar, with access clarity and operational transparency both at 92.1, while contract governance sits at 22.0. Agent Readiness is 43.7, agent-ready. Reversibility is documented and the MCP server is lit; idempotency and dry run are unlit. The agentic access profile counts 280 operations, 133 acting and 10 human-in-the-loop.
So what do you take away? Keep the question about "mergeable" and use Snyk's definition when you ask it of anyone. Treat 90.2% as a vendor figure for the CLI engine, not a promise for campaigns. And note that Snyk's own design keeps a person on the merge, which is the right place for this agent. The record has less to say for the next agent, the one calling Snyk's API with no such person behind it.
Read the original: https://apis.io/2026/10/30/snyk-sends-its-remediation-agent-after-the-backlog-in-campaigns/