Library clerks install an unofficial 'productivity' LLM browser extension on workstations that handle patron records. What supply risk is that?

Unofficial LLM browser extensions on library workstations that handle patron records expand the AI supply chain to the endpoint. Extensions can read DOM content, cookies, and form fields, exfiltrate queries, or inject prompts into staff workflows—creating endpoint plugin supply risk that bypasses server-side RAG controls. Assessments correctly classify this as civic workstation supply-chain exposure and recommend allow-listed extensions, MDM enforcement, and removal of sideloaded productivity helpers. Patron privacy obligations make unsigned LLM extensions especially inappropriate on clerk machines.

A third-party vendor patch in library catalog software, an open-source dependency in the public catalog search service, and a managed service provider for library network maintenance are all supply-chain issues elsewhere in the stack — none of them names the actual finding, which is unmanaged endpoint supply risk from an unofficial, unvetted LLM extension on workstations handling patron records.

Exam caveat: an open-source dependency in the public catalog search service is a backend component issue, not the endpoint browser-extension exposure at the heart of this question. Operational check: inventory browser extensions via MDM, block non-allow-listed IDs, remove the unofficial LLM helper from clerk profiles, verify patron-record pages cannot be read by residual content scripts, and document the allow list in the library AI acceptable-use standard.