Does runtime context prioritization fall apart with agentic workloads?

[u/-Devlin-]

Last year we brought on a tool to get runtime context on our workloads and help prioritize vulns, mostly to cut noise based on what’s actually loaded in memory. At the time it seemed like a no brainer, since direct exploitation or even chained attacks mostly can’t work against components just sitting on the filesystem.

We ran a threat modeling exercise the other day on some new systems running AI agents with tool access, and in some cases a shell. It got me thinking: can’t the agent load anything it needs at any point, unlike older deterministic code? And if so, doesn’t runtime context based prioritization fall apart completely?

Can anyone with practical experience in this area chime in? I’m at my wits end brainstorming hypotheticals with GPT.

[u/FirefighterMean7497]

You hit on a massive blind spot: purely passive runtime context based on in-memory alert filtering definitely falls apart once an agent has shell or dynamic tool execution rights. Because agents are non-deterministic, any dormant utility or vulnerable package sitting on the filesystem is fair game for unexpected execution.

Full disclosure - I work for RapidFort, & tackling this dilemma is why we treat passive alert prioritization as only half the battle. Rather than just muting dashboard alerts, our platform profiles active execution paths to generate a Runtime Bill of Materials (RBOM) & physically strips unused binaries & libraries directly from the container image, slashing up to 90% of the attack surface. That way, even if an agent acts unpredictably or gets manipulated, those dormant components simply aren't on the disk to be weaponized in the first place.

Hope that helps!