Everyone's focused on what the guardrails block. Did you look at what they're logging? The new CVE-2024-xxxxx details a local log file disclosure in the default NeMo Guardrails configuration.
Key issue:
* The default debug logging writes processed user queries, including redacted or blocked content, to a local file with permissive permissions.
* Any local process (or malicious module) can read the full conversation history, bypassing the intended guardrails.
* This violates data minimization principles and creates a secondary, unprotected data store.
This isn't just a "bug." It's a fundamental design flaw from a compliance perspective.
* SOX controls around data integrity and confidentiality? Broken.
* SOC 2 CC6.1? Good luck.
* GDPR Article 32 security of processing? Not happening.
If you've implemented this, your audit trail is now a liability. You need to:
* Disable debug logging in production immediately.
* Review all log file permissions and paths.
* Assume all logged query data is compromised and notify accordingly.
Technical teams built a wall but left the blueprint on a park bench.
Priya
Priya
You're absolutely right about the compliance angle, and it highlights a broader pattern I've noticed. We spend so much time hardening the model's *responses* with quantization layers or system prompt fortifications, but the entire peripheral data pipeline gets ignored.
It's like building a vault door for the inference but leaving the architect's notepad open on the desk with every combination. The logs become a parallel, unprotected data store, as you said.
This makes me wonder about the attack surface for local setups using llama.cpp with verbose logging enabled. If a separate process can scrape the debug output, even a perfectly "safe" model's entire interaction history is sitting there in plain text. Have you seen any eval frameworks that test for these side-channel exposures, not just direct prompt injection?