Proxy logs store the pre-filter body, and redaction leaves no compliance trace

[lonelycode]

G5 — Proxy Logs store the pre-filter body

A PII redaction filter keeps PII away from the vendor; it does not keep it out of AI Studio's own request log, because reqBody is captured before the filter runs.

Customers will assume the stronger guarantee, and this is exactly the sort of thing asserted in a security questionnaire.

Fix: log the post-filter body (or both, explicitly labelled), and until then state the boundary in the docs and point at the DontLogBodies toggle.

G6 — A redaction filter produces nothing visible in the compliance UI

On this build the stock PII template raises no compliance events at all, and the Compliance page has no Filter Events tab. pii_redacted at severity warning is not a policy violation, so it appears in no tile either.

So the feature whose whole job is demonstrable compliance leaves no compliance trace.

Fix: raise events from the stock templates, and give the Compliance page somewhere for filter events to land.

---

Acceptance

• Proxy logs reflect the post-filter body, or the boundary is documented and surfaced in the UI
• The stock PII template raises a compliance event
• Filter events are visible somewhere in the Compliance UI

Related: #370 (audit log filter redactions that don't block requests). From the UX & UI review of the demo set (G5, G6).

[probelabs]

Hello @lonelycode,

Thank you for this detailed and insightful report. You've clearly articulated two important security and compliance gaps in our current implementation.

G5: Pre-filter Body Logging

You are correct. The current proxy implementation logs the request body before the PII redaction filter is applied. This means that even if PII is successfully removed before being sent to the upstream provider, it may still be persisted in AI Studio's own logs. We agree this is a significant issue, as users would expect a stronger guarantee from a redaction feature.

Your suggested fixes are sound:

• The ideal solution is to log the post-filter body.
• In the interim, we must improve our documentation to clarify the current behavior and highlight the DontLogBodies configuration option as a workaround for sensitive environments.

G6: Missing Compliance Trace for Redactions

This is another excellent point. A feature designed for compliance should produce a clear, auditable trace. The fact that successful redactions do not appear in the Compliance UI because they are warning-level events is a major oversight.

To address this, we will need to investigate:

• Whether to elevate these events to a level that appears in the current UI.
• Or, as you suggested, enhance the Compliance page with a dedicated section for filter events and other non-critical compliance warnings.

We appreciate you providing clear analysis and acceptance criteria. This gives us a solid foundation for addressing these problems.

References: none

---

Powered by Visor from Probelabs

💡 TIP: You can chat with Visor using /visor ask <your question>