Applications break when they assume only known CVEs matter. The article shows that exploitability can emerge from library behaviour even when the specific attack is not cataloged or the payload varies. Without runtime detection, teams may miss active exploitation for weeks or months, giving attackers time to run code, steal data, or move deeper into the environment.
Why vulnerability lists fail as a sole control for LLM applications
Vulnerability lists only tell you what has already been named, scored, and published. For LLM applications, that is a narrow view because the useful detection signal is often runtime behaviour: prompt patterns, tool misuse, abnormal API calls, unexpected data egress, and execution paths that do not look like a textbook CVE. Teams need live visibility into the application’s actual actions, not just its catalogued weaknesses.
A practical example is the gap between a known flaw and a real exploit path. An attacker may abuse a library behaviour, configuration, or integration pattern that was not yet turned into a formal vulnerability record, so a CVE feed will stay silent while exploitation is already underway. That is why runtime observation belongs alongside vulnerability management, especially where the model can call tools, reach data, or trigger downstream actions.
For teams building or operating these systems, the best analogue is to treat the application as a moving target. If the control plan depends only on a list, you are assuming the threat is fully enumerable in advance. In LLM environments that assumption breaks quickly because the attacker can vary the payload, change the orchestration path, or use the model’s own behaviour to reach a harmful state.
- runtime detection catches misuse that never becomes a named weakness.
- Vulnerability lists help with prioritisation, but they do not prove safety.
- Detection should watch the model, the tools, and the data flows together.
What runtime detection adds that CVE tracking cannot
Runtime detection answers a different question: what is the application doing right now, and is that behaviour consistent with intended use? For LLM systems, that means observing prompts, tool invocation sequences, token usage, unusual file access, lateral movement into connected services, and attempts to exfiltrate sensitive context. The value is not only alerting, but also proving whether a suspicious pattern is actually operational in your environment.
That distinction matters because many LLM failures are compositional. A single component may look benign, while the combination of model output, orchestration logic, plugin access, and downstream credentials creates the breach path. A static vulnerability list cannot model every live combination, but runtime detection can expose the moment an attacker crosses from harmless interaction into active abuse. NHI Mgmt Group’s Ultimate Guide to Non-Human Identities is useful here because it shows how broadly overprivileged access and poor visibility amplify damage once an application is being abused.
That is also why detection quality matters as much as detection presence. If alerts are too coarse, teams will miss the sequence that matters, such as prompt injection followed by tool abuse and then data movement. If alerts are too late, attackers can already have run code, accessed sensitive information, or persisted in adjacent systems. Runtime telemetry should therefore be tuned to detect behaviour that is suspicious even when no formal vulnerability record exists.
One useful benchmark is the scale of exposure from poor visibility itself. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, which is a reminder that blind spots are common once systems rely on delegated access paths. In LLM applications, the equivalent blind spot is assuming that a clean vulnerability list means a clean runtime.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 8 — Audit Log Management | Runtime detection depends on logging model and tool actions in live use. |
| CIS Control 7 — Continuous Vulnerability Management | Vulnerability lists still matter for known issues and patch prioritisation. | |
| Recommendation — Collect and review logs for prompts, tool calls, and anomalous application actions. Maintain continuous vulnerability scanning, but pair it with runtime detection. | ||
| NIST CSF 2.0 | DE.CM — Security Continuous Monitoring | The question is about catching active abuse through live monitoring, not static inventories alone. |
| DE.AE — Anomalies and Events are Detected | LLM abuse often appears first as anomalous prompts, tool use, or data movement. | |
| PR.PT — Protective Technology | Runtime controls and telemetry are needed to complement vulnerability-based assurance. | |
| Recommendation — Monitor runtime behaviour so active exploitation is detected before damage spreads. Tune detections to flag anomalous runtime behaviour and investigate deviations quickly. Deploy protective controls that observe and constrain live application behaviour. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | LLM tool abuse can result in code or command execution paths similar to ATT&CK execution techniques. |
| T1530 — Data from Cloud Storage | Runtime detection should catch attempts to access or exfiltrate sensitive data during abuse. | |
| Recommendation — Map suspicious model-enabled execution to ATT&CK techniques and hunt for follow-on activity. Alert on abnormal data access and exfiltration patterns tied to application runtime. | ||
Practitioner Guidance
What to prioritise: Put runtime signals around the actions that can create material impact, especially tool calls, file access, outbound requests, and privileged workflow steps. A vulnerability feed should inform patching and triage, but it should not be the only mechanism used to decide whether an LLM application is under active abuse.
What to verify: Confirm that you can trace a suspicious model interaction from prompt to tool use to downstream effect. If you cannot reconstruct that chain, you do not have enough evidence to distinguish harmless novelty from active exploitation.
Common mistake: Treating “no published CVE” as “no security problem.” In practice, the more connected the application is to data and execution, the more valuable behavioural detection becomes, because the first sign of compromise may be an odd sequence rather than a known signature.
Practitioner takeaway: The right control objective is not to replace vulnerability management, but to prevent unknown or unlisted abuse from staying invisible long enough to matter.
Related resources from NHI Mgmt Group
- What breaks when teams rely on vulnerability lists instead of attack graphs?
- What breaks when teams rely on static vulnerability scoring instead of runtime reachability in Kubernetes?
- What breaks when organisations rely on audit logs instead of runtime enforcement?
- What breaks when AI agents discover tools at runtime instead of using hardcoded lists?
