A water utility stores embeddings of valve manuals on a vector service left on default public networking. What infrastructure exposure should security fix?
Select an answer to reveal the explanation.
Short Explanation
Valve manuals in a vector DB on the open internet is like leaving the plant blueprints on a park bench. Pull that service onto private networking and lock who can query it.
Full Explanation
Network exposure of the municipal vector database that can leak or allow abuse of operational knowledge is the infrastructure issue to fix. Embeddings of water-utility valve manuals on a vector service left on default public networking place OT-adjacent operational content on the open internet. Attackers can query, scrape, or abuse the endpoint to map plant procedures. Place the vector service on private networking, restrict callers via identity-aware proxy or private endpoints, and treat the index like other sensitive operational stores.
Claiming public networking improves high availability for OT-adjacent manuals fails by concept: availability does not require world-readable vector APIs, and exposure increases sabotage and reconnaissance risk. Asserting embeddings never contain operational detail fails because chunk text and metadata often retain procedure content, and even dense vectors can support inversion or nearest-neighbor leakage of related text. Saying default public endpoints are required for RAG citation hyperlinks fails because citations point at authorized document URLs; they do not require a publicly open vector query API.
Exam caveat: Vector databases are data stores. Default-public cloud endpoints for municipal operational knowledge are misconfigurations, not RAG requirements.
Operational check: Move the vector service to private networking, require authenticated app identities for query, confirm internet clients time out, review firewall and private-link settings with utility OT security, and inventory other RAG indexes for the same exposure.