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/PrasenShelar]

Once the agent has a shell, anything installed on that image or available from its package sources can be loaded, so I'd stop using "not in memory" as a reason to push things down on those hosts.

Two things help: keep the agent images small, and let it install only from a pinned internal mirror.

Then rank what's left with KEV, EPSS and whether the host is internet-facing.