Fire/EMS evaluates an LLM assistant that returns clickable links in replies. Which threat should vulnerability management emphasize?

An LLM assistant that returns clickable links introduces insecure output handling risk: clients may render or open unsafe URLs emitted by the model without sanitization. Vulnerability management should emphasize this threat because generative text is untrusted content; phishing, malware hosting, or misleading municipal look-alike links can ride assistant replies into Fire/EMS or public user workflows. Treating model output as untrusted until validated works as the core control philosophy for civic assistants that emit actionable links.

Training data poisoning that could cause models to memorize unsafe links from compromised development datasets fails as a vulnerability-management emphasis because it describes an upstream training-time source of bad URLs rather than the client-side failure to validate and sanitize links before clients execute or open them from replies. Prompt injection in retrieved incident records that could cause clients to open unsafe links from replies fails as the emphasis here because it names an input-side trigger that might induce a bad link, rather than the insecure output handling controls that determine whether clients execute or open unsafe links emitted by the model. Resource exhaustion from complex queries that could cause clients to open unsafe links during operations fails as the emphasis because exhaustion degrades availability through delays during operations and does not cause clients to execute or open unsafe links from replies.

Exam caveat: markdown auto-linking and mobile clients can increase click-through risk even when desktop users are cautious. Operational check: strip or rewrite links through an allow-list of municipal domains, display raw URLs with warnings for off-domain targets, enable safe-browsing checks on click, and include malicious-link emission cases in red-team tests for the assistant.