A housing-authority RAG service logs full retrieved chunks—including resident SSNs—into debug traces. What data-path risk should security remediate?
Select an answer to reveal the explanation.
Short Explanation
The retrieve step already touched the SSN; dumping those chunks into debug logs just photocopies the problem into Splunk. Redact or drop sensitive retrieval payloads from observability—don't treat logs as a second case file.
Full Explanation
Sensitive retrieval content entering observability pipelines expands leakage and retention risk, which is what security must remediate. When the housing-authority RAG service logs full retrieved chunks that include resident SSNs, debug traces become a second copy of highly sensitive data outside the case system’s normal controls. Those logs may be broader ACL’d, longer-retained, and discoverable under public-records or breach analysis. Redact, hash, or drop sensitive retrieval payloads from traces; keep operational metrics without photocopying SSNs into Splunk.
The claim that vector indexes cannot contain SSNs by mathematical design fails by concept: embeddings and especially logged chunk text can and do carry identifiers present in source documents. Asserting debug logging is immune to public-records discovery fails because logs are records subject to policy and law, not a privileged side channel. Leaving SSNs unredacted in logs “for fraud detection” fails by creating unjustified retention and exposure when purpose-built fraud tooling and minimized fields should be used instead.
Exam caveat: Retrieval paths and observability paths are both data paths. Civic privacy controls must cover what RAG puts into prompts and what it writes to logs.
Operational check: Inspect debug templates for raw chunk bodies, enable redaction of SSN-like patterns, verify a retrieve of a fixture with a synthetic SSN leaves no clear identifier in traces, and set retention on observability stores consistent with housing data policy.