Designing a Privacy-First Architecture for Sensitive Data: Zero-IP Logging, Postgres RLS, and AI Safety

Victor B Vieira — Mon, 14 Sep 2026 18:32:41 +0000

When building software that handles sensitive human data (like workplace feedback, satisfaction surveys, and compliance reports), security and privacy cannot be treated as optional features or mere legal disclaimers. They must be embedded into the core system design.

At Sigilo Profissional (sigiloprofissional.com.br), a B2B SaaS platform focused on Workplace Climate Surveys, eNPS, and Whistleblowing Channels compliant with ISO 37002 and GDPR / LGPD, privacy is the fundamental prerequisite for psychological safety. If employees do not trust the platform's anonymity, engagement drops to zero.

Here is a breakdown of the security architecture and privacy controls we implemented in our Python (FastAPI) and PostgreSQL stack.

1. Dual-Layer Multi-Tenancy (Application + PostgreSQL RLS)

To prevent cross-tenant data leakage, we enforce tenant isolation at two independent layers:

Application Layer: Every query filters by firm_id within SQLAlchemy.
Database Engine Layer: PostgreSQL Row Level Security (RLS) is enabled on all tenant tables. The application middleware sets SET LOCAL app.firm_id per database session.

-- Enforcing PostgreSQL Row Level Security (RLS)
ALTER TABLE tenant_complaints ENABLE ROW LEVEL SECURITY;

CREATE POLICY firm_isolation ON tenant_complaints
  USING (firm_id = current_setting('app.firm_id')::uuid);

Why both? Even if a bug or missing filter occurs in application code, the database engine natively blocks access to data outside the active tenant context.

2. Zero-IP Logging Policy & Anonymous Protocol Tokens

To ensure complete whistleblower anonymity:

Proxy-Level IP Stripping: NGINX and edge proxies strip X-Forwarded-For and client IP headers. No IP addresses are saved in NGINX logs, application memory, or database records.
Cryptographic Tokens: Anonymous reports are tracked strictly through random protocol tokens (e.g., SGL-2026-7X3K). Whistleblowers can check updates using their protocol token without ever creating an account or storing session cookies.

3. PII Anonymization for Responsible AI Features

We use Large Language Models (LLMs) to assist employees in structuring clear reports and to summarize qualitative eNPS sentiment for management.

To prevent sensitive Personally Identifiable Information (PII) from being sent to external AI models:

Requests pass through an intermediate LiteLLM proxy layer that sanitizes names, emails, phone numbers, and location metadata before dispatching prompts.
AI outputs are strictly used for guidance and categorization, never for autonomous decision-making.

4. Immutable Audit Trails

Compliance frameworks (such as ISO 37002) require full auditability for compliance officers. We maintain immutable audit logs for administrative actions (e.g., status updates, report triage) using cryptographic hashing, ensuring complete transparency without compromising whistleblower anonymity.

💬 Community Question: What Are We Missing?

As we continue scaling our engineering stack, we are reviewing our security roadmap.

We would love feedback from the Dev.to community:

What automated query auditing or key rotation strategies do you recommend for multi-tenant Postgres RLS at scale?
Have you implemented additional client-side payload encryption patterns that balance searchability with absolute zero-knowledge privacy?

Looking forward to your thoughts and suggestions in the comments!