Agentic vulnerability management, end to end: 2,731 findings, one approved fix
.png)
Falco Feeds extends the power of Falco by giving open source-focused companies access to expert-written rules that are continuously updated as new threats are discovered.
How Sysdig agentic cloud security works
TL;DR: In a live Sysdig Secure AI session, agents triaged a 119,443-finding backlog, traced 2,731 SLA-breaching findings to a single base-image fix, and a human approved the resulting Jira ticket, DEJI-342. The same agents run headless in Claude through Sysdig's MCP server.
Anyone who has owned a vulnerability program knows the uncomfortable part: The findings were never the problem. Knowing is easy. A scanner will happily hand you six figures of findings by lunchtime. The problem is the distance between knowing and doing: mapping a CVE to the workloads it actually affects, hunting down an owner, opening the ticket, and tracking the SLA. That distance is measured in analyst hours, and analysts are the scarcest resource in the building.
That gap was "survivable" when attackers moved at human speed. They don't anymore. The Sysdig Threat Research Team recently documented JADEPUFFER, the first agentic ransomware operation, an extortion campaign driven end to end by an LLM. And our 2026 Cloud-Native Security Report put a number on the shift: Attackers now weaponize disclosed vulnerabilities within hours. The old pain didn't change. The clock did.
This is where the agentic model changes the math. Below is a walkthrough of Sysdig Secure AI working on one of the hardest jobs in security, captured from a live environment. If you'd rather watch than read, here's the video version:
You set the operating orders
Agents don't get free rein. They get goals. Setup starts the way any risk conversation should: Tag your high-value assets, then define SLA windows per severity. In this environment, criticals and highs must be remediated within 30 days.
Goals become standing plans
Secure AI turns those policies into standing plans; in this case, SLA Compliance and Reduce Exposure Time. This is the shift that's easy to miss: The agents aren't working a task list. They're working toward an outcome.
That difference is everything. A task queue is something you fill, drain, and refill, and the moment it's empty, the work stops. A plan is a goal the agents pursue continuously, and the goal is yours. It comes from your team's SLAs, your risk tolerance, and your definition of acceptable exposure. You set the purpose, and the agents drive toward it day after day, without anyone reloading the queue.
The agent works the metric, not the ticket queue
Open the SLA Compliance plan and the agent reports like a colleague. It will tell you things like current value 28.3%, up 2.9 points versus the prior day, with the reasoning written out: what the plan tracks, which findings count toward the metric, and how the queue was ranked. It maintains a ranked list of the jobs that move the metric the most. No analyst had to notice anything for this queue to exist.
The verdict: Runtime context, not CVSS guesswork
The top-ranked job resolves to a verdict a human can act on: One Node.js image (node:17.9.1-bullseye) is carrying 2,731 SLA-breaching findings, 273 of them critical, and the oldest is 90 days past the deadline. A maintained Node 17 base image resolves them. This is runtime insights doing the prioritization rather than a spreadsheet of CVSS scores. This particular plan ranks by the severity of the worst SLA breach and limits itself to findings that already have a published fix, so the queue only contains work your team could ship today. Other plans lean on different runtime signals: Reduce Exposure Time ranks by risk score, findings, and age, and the headless queries later in this post rank by EPSS exploit probability with CISA KEV checked.
The underlying signal is worth being precise about, because plenty of tools now claim reachability. Most of them mean static reachability, a path that theoretically exists somewhere in the dependency graph. Sysdig's runtime reachability is stricter: the vulnerable package is loaded into a running process right now, with workload exposure evaluated as a separate signal on top. It is the difference between what could be reached and what is actually running. Tracing a backlog that size to one actionable fix is the work that normally eats an engineer's whole day. The agent walked in with it done.
A human stays the control point
The agent drafts the remediation ticket (summary, impact, suggested fix) and asks exactly one question: who owns it? Then a human reviews and clicks Approve. That click is the entire autonomy debate resolved in one UI element. Agents do the analysis, people authorize the change.
A real ticket, carrying the full why
Seconds after approval, it's a real Jira ticket, DEJI-342, assigned to its owner, labeled generated-by-sysdig, and carrying the complete reasoning: why this job matters, the SLA math, and the remediation suggestion. SLA tracking picks it up automatically. Nothing here is a mockup; it's the Jira instance the demo environment is wired to.
The same brain, headless in your AI assistant
That's the console. But your engineers increasingly live in code editors and AI assistants, so Sysdig ships the same capability headless, through the Sysdig MCP server (open source on GitHub).
Three things travel with it, and it's worth separating them, because most "agentic" tooling only has the first. The server is the access. It exposes runtime data to the assistant. The skills are the know-how: a decade of Sysdig expertise in how to rank a finding by real exploitability, trace a six-figure backlog to a single fix, and resolve a safe upgrade path without introducing new criticals. And the agentic workflow is the part that doesn't wait to be asked. The same standing plans from the console, SLA Compliance and Reduce Exposure Time, keep running and keep ranking the backlog, so the fix is already surfaced before your engineer types a word.
That's the difference. Anyone can wrap a few API calls in an MCP server and call it "agentic." Plumbing gets you access. Skills get you a good answer. The agentic workflow means the answer is already waiting.
Here it is inside Claude. Note what the permission prompt exposes: the exact tool and the exact query.
Allow Claude to use List Vulnerability Findings
(Aws-us1 Sysdig Secure MCP Server)?
{
"severity_in": [
"critical"
],
"limit": 5,
"hasFix": false,
"hasExploit": false
}
Live answers from runtime
Ask for the top five criticals and the answer comes from runtime, not a stale export. All five, including CVE-2026-55200 and three CVE-2026-32740 libheif variants, sit on one nginx service on ECS Fargate, ranked by EPSS exploit probability with CISA KEV checked. Same plans, same data, different interface. That is the point.
The guardrails are explicit
Say yes to remediation and the agent launches the Sysdig Remediate skill. Before it runs, it states its rules of engagement, and this is where "agentic" either earns trust or doesn't:
- It will fetch the critical and high CVEs affecting the image, resolve a safe fix version through chain analysis (skipping upgrades that introduce new criticals), draft the patch, and update the tracking ticket.
- It will not commit or push to repositories, log or display credentials, or change anything without explicit approval. When prerequisites are missing, it detects that and asks how to proceed: pull request, or local patch file.
What the workflow looks like, before and after
The economics follow the same curve, and the ceiling is the number to watch. A human-only team tops out near 925 investigations a year, because the constraint is analyst hours and there are only so many of them. The agentic workflow runs above 10,000 a year, and the constraint stops being your people. The cost math is favorable too: our internal analysis puts a human-only investigation at roughly $135, and the agentic workflow at about $16, AI token costs included, an 88% reduction. But the cost figure is the ammunition you bring to your manager. The ceiling is what actually changes what your team can defend.
Figures from Sysdig internal analysis; your environment and rates will vary.
The bigger shift: One brain, every interface
The specific feature here is vulnerability management. The bigger story is architectural. The same agents, the same plans, and the same runtime data are available in the Sysdig UI for your humans and as headless tools for your AI assistants: one brain, every interface. It's the same direction we set with agentic cloud security and Sysdig Sage, and it's why runtime, not posture, is the defensible ground: Agents are only as good as the data they reason over, and runtime is the only data that says what's true right now.
And the agents are only as good as the expertise driving them. The MCP plumbing is table stakes that anyone can copy. A decade of Sysdig knowing which finding actually matters, encoded into the skills that do the work, is not.
Attackers made their move to machine speed. The 555 Benchmark was our answer for detection and response. Agentic vulnerability management is the same answer for the backlog: fix at the speed the findings arrive, with humans deciding what ships.
If you own the backlog, see it run against your findings. The demo is on your environment, not ours. If you'd rather start with the headless workflow, the Sysdig MCP server is open source on GitHub.
Frequently asked questions
What is agentic vulnerability management?
AI agents that work toward goals you set, like SLA compliance, on live runtime data: they triage continuously, rank the fixes that reduce the most risk, draft remediations, and route every change through human approval.
Do the agents make changes without approval?
No. In the UI a human approves each ticket. In headless, every tool call is permission-scoped, and the remediation skill will not commit, push, or touch credentials.
How is this different from CVSS-based prioritization?
CVSS is theoretical severity. The agents rank by what's actually loaded, exposed, and exploitable (EPSS probability, KEV status, and runtime reachability, meaning the code is loaded in a running process, not just present in the graph), then group findings by the single fix that resolves the most of them.
Can I use it from Claude or other assistants?
Yes. The same agents, plans, and runtime data that power the UI are exposed to any MCP-capable assistant through the Sysdig MCP server, so the agentic workflow keeps running whether or not anyone is logged into the console. It is not a chatbot bolt-on. It is the same brain your team uses, reachable from wherever your engineers already work.
How is this different from any other MCP server?
An MCP server on its own is access: it exposes data to an assistant. Sysdig ships three layers. The server provides the access. The skills provide the know-how, a decade of Sysdig expertise in how to rank a finding by real exploitability, trace a six-figure backlog to a single fix, and resolve a safe upgrade path without introducing new criticals. The agentic workflow is the layer that does not wait to be asked: the same standing plans keep running and keep ranking the backlog, so the fix is already surfaced before an engineer types a word. Plumbing gets you access. Skills get you a good answer. The agentic workflow means the answer is already waiting.
See it on your findings, not ours.
Requeset a Sysdig Secure AI demo today