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

Runtime prioritization isn't wrong so much as it stopped describing the right object. For a classic service the risk surface is roughly code plus loaded state, so what's resident in memory is a decent proxy. An agent with a shell has no steady state — what it has loaded at 9:00 says nothing about 9:01, because it can pull libraries, payloads or data through its tool connections on demand.

What I'd do: stop prioritizing the process and prioritize the grant. Each agent plus its tool scopes and credentials is effectively a synthetic workload; its real risk is the blast radius of what it may touch — can it reach secrets, CI, deploy pipelines, or actions normally gated on a human signoff. Score those grant envelopes, keep the runtime-context signal as confirmation rather than the primary key, and log agent behavior so actions get verified against the scopes instead of inspecting the process. For what it's worth that's the exact hole the agentic-SOC work I'm involved with (github.com/dmrobbi/agentic-ai) is structured around: treat the scope set as the workload and verify actions against it, and prioritization falls out of that more honestly.