With the pace of vulnerability discovery increasing and the window between disclosure and exploitation shrinking, or even becoming negative in certain cases, there is a lot of pressure on security teams to move fast. This pressure is exacerbated by the constant (and successful) advertising from AI companies reaching audiences that are not familiar with the security space, but that very much care about the optics of having secure environments. “How are we using AI to secure our company?”, “Have you seen that Mythos found 271 vulnerabilities in Firefox?” and “Can we have agents regularly scanning our codebases?” might have become too familiar at this point.
\nNow don’t get me wrong, having more people caring about security is a great outcome, but blindly throwing agents at the problem will not necessarily benefit most companies as we will see below. Even with unlimited budget and staff, it’s unrealistic to expect that companies will find, prioritize and patch every issue in their supply chains before they are discovered and exploited by attackers. Focusing on the fundamentals is more important than ever and will give your company the ability to leverage agents in an impactful manner.
\nThere are much better sources discussing the fundamentals of a successful Vulnerability Management program, so let’s focus instead on relevant scenarios and see how having these fundamentals in place is often enough. After focusing on the benefits of strong fundamentals we will also discuss how agents can be leveraged and the benefits they bring to the table.
\nYour team is made aware that axios has been compromised and versions 1.14.1 and 0.30.4 were shipped with a RAT. You know that your organization has established dependency cooldown periods, so it is highly unlikely to be affected. Doing your due diligence, you query the comprehensive asset inventory and are quickly able to assess that these versions were not pulled by developer machines or any other environment. Furthermore, you write a quick rule to block these packages from being fetched from your unified repository like Artifactory, Nexus or Cloudsmith.
What could have been a long incident is resolved in a matter of minutes since your company had the required data and processes in place. The most successful incidents are the ones that didn’t happen.
\nPlot twist
\nAn acquisition wasn’t using the unified repository and was able to pull the vulnerable dependency. Luckily the environments had clear egress rules in place, so the RAT could not reach out to the attacker’s domain. The team figured this out since they were monitoring for the indicators of compromise. Yet again, what could have been a catastrophic incident becomes an action item.
\nWhat about agents?
\nWith the foundations in place, agents would also be able to query the same APIs and automatically create the required blocking rules. Security engineers would be able to quickly assess the agent’s decision and merge the rules. The outcome remains the same, but the triaging and response time is shortened. Agents could also be leveraged to extract the indicators of compromise from a particular source, monitor systems for it and alert the team in case of matches.
\nYour team is made aware of Copy Fail, a new local privilege escalation vulnerability. This is an interesting case since there are no patches upstream at the time, so you quickly write some detection rules while the organization figures out how to handle this situation. Since the organization has invested in clear threat models for their main surface areas, the team makes well informed decisions about waiting for the official patches versus manually patching systems. Runbooks detailing how to patch and cycle hosts are in place for systems that require manual patching, so teams can safely patch and cycle involved hosts without guess work. Patches to disable the algif_aead module or modify seccomp policies are put in place, and since the organization has invested in observability, it’s easy to track the percentage of the fleet that still needs to be cycled.
What about agents?
\nAgain, agents could be leveraged to speed up parts of the triaging and detection pipelines by writing the necessary detection rules and help with monitoring. Unless agents have full access to your deployment and infrastructure pipelines, which has many other downsides, it wouldn’t be able to patch and cycle your fleet. It also wouldn’t be able to make the correct business decisions like reasoning about the need to patch versus a potential downtime incurred by a redeploy.
\nYour team is made aware of critical CVEs in vim and emacs. The organization has invested heavily in keeping an inventory of applications in use within developer machines and have a well established pipeline to block applications from running through Santa rules. It also has an inventory of package versions that can identify when a vulnerable version is present within hosts.
\nWhat about agents?
\nIn this case an agent could use the available data to decide whether applications can be directly blocked using an heuristic like the number of machines using the vulnerable versions and also cycling hosts if newer images are available with the patched versions
\nYes and no. In most cases agents can speed up the mean time to triage and remediation, but they wouldn’t be as useful without being able to rely on a strong foundation. If your company has clear foundational gaps, agents will hardly be the solution to the problem despite the push to rely on them. If you feel your company is already well positioned to benefit from agents, I recommend you start focusing on the triage side of things. Having the right information at the right time allows you to make the best decisions for your team and company.
\nThat being said, with a strong foundation in place a lot of the triaging steps can be made deterministic, in which case agents can actually be a detriment to the process.
\nWhat else?
\nOne area where agents can shine is when they are leveraged to scan 1st party code and infrastructure. This covers both proactive discovery in our own code and also the aspect of figuring out if we are affected by a particular zero day (no patch or CVE). Companies have a huge advantage leveraging their full context to find relevant vulnerabilities. By leveraging artifacts like system designs and threat models, agents can find highly contextual vulnerabilities that when coupled with an automatic validation pipeline delivers valuable findings to internal teams. Figuring out a way to quickly spawn a testing environment with everything that an agent needs to replicate a vulnerability is a worthy problem to tackle.
\nAgents are also great at performing simpler versions of reachability analysis, which can be particularly useful when assessing impact from unpatched library vulnerabilities. When used right, they can augment your risk based prioritization process in a meaningful way.
\nIf you are still looking for more ideas, agents can also crawl your runbooks and ensure they are up to date. They can also map outbound network connections against declared egress rules and even compare crawled infrastructure against the current asset inventory.
\nWith all that said, and sounding like a broken record at this point, before you go all-in on agents ensure a strong foundation is in place. They will give agents the data they need in order to make better decisions. Starting with agents is backwards.
","frontmatter":{"title":"Vulnerability Management in the age of AI","date":"May 04, 2026","description":"Agents accelerate vulnerability management, but only when the foundations are already in place."}},"previous":{"fields":{"slug":"/kamal-proxy-security-audit/"},"frontmatter":{"title":"kamal-proxy security audit"}},"next":null},"pageContext":{"id":"906728ed-a800-58a5-b5d0-89f92337c980","previousPostId":"cc7fcdc5-4049-5f89-9a2c-71f212a1a9a0","nextPostId":null}},"staticQueryHashes":["2841359383","916993862"]}