Security Middleware

PII Privacy Gateway

An Omninex privacy layer for in-memory payload scrubbing, runtime log redaction, and secure API workflows before sensitive data reaches logs, LLM providers, or downstream systems.

FastAPI Python Pydantic Regex Tokenization Luhn Validation Structured Logging

Review Architecture Back to Products

Detect Mask Protect

Built for privacy-aware API workflows, developer logs, and technical enablement environments

Product Overview

Sensitive-data controls before exposure.

PII Privacy Gateway is designed as a defensive middleware layer. It receives application payloads, applies redaction logic, and helps prevent sensitive values from leaking into logs, support traces, training artifacts, or external processing workflows.

In-Memory Payload Scrubbing

Sanitizes sensitive values before payloads are logged, persisted, or forwarded to downstream services.

Runtime Log Redaction

Intercepts application logs at the boundary so sensitive values do not leak into consoles, traces, or observability sinks.

Deterministic Validation

Combines pattern matching with validation logic to reduce false positives when detecting structured identifiers.

Architecture

Gateway-first redaction flow.

The architecture keeps the redaction boundary close to the application entry point and applies a second control at the logging boundary.

1. API Gateway Layer

FastAPI receives structured JSON payloads, validates request shape with Pydantic, and forwards only clean payloads through the workflow.

2. Gollog Redaction Engine

The core redaction layer applies configured rules, tokenization, and validation logic before sensitive data reaches logs or downstream processing.

3. Log Interceptor

A logging boundary catches outgoing application messages and applies final redaction before output reaches stdout, files, or cloud logging systems.

PII Privacy Gateway Data Flow

graph TD
  A[Client Request] --> B[FastAPI Privacy Gateway]
  B --> C[Gollog Redaction Engine]
  C --> D[Rule Manager]
  C --> E[Regex Processor]
  C --> F[Luhn Validator]
  D --> G[Sanitized Payload]
  E --> G
  F --> G
  G --> H[Clean API Response]
  B -.-> I[Log Interceptor]
  I -.-> J[Scrubbed Logs]

Redaction Evidence

Raw values become safe operational output.

These examples show the intended behavior: sensitive values may exist in incoming payloads or debug messages, but the protected output masks them before operational exposure.

Log Source	Raw Output	Protected Output
API Request Log	Received payload: {"ssn": "000-12-3456"}	Received payload: {"ssn": "[REDACTED-SSN]"}
Auth Debugger	Login attempt: AKIAIMNOSTEST123	Login attempt: [REDACTED-AWS-ID]
Validation Error	Failed card: 4111111111111111	Failed card: **--**-1111
System Exception	Timeout: j.doe@example.com	Timeout: [REDACTED-EMAIL]

Security Rationale

Reduce leakage before it becomes infrastructure history.

Many data leaks do not start in the database. They appear first in debug statements, failed validation messages, support traces, observability stacks, or training screenshots. This gateway pattern reduces that risk by sanitizing early and intercepting logs before persistence.

$ privacy-gateway inspect payload

# input contains identifiers

$ privacy-gateway redact --policy default

# output safe for logs, demos, and downstream processing

Roadmap

From prototype to deployable privacy utility.

Presidio Evaluation

Evaluate Microsoft Presidio for ML-assisted entity recognition alongside the current deterministic rules engine.

Container Deployment

Package the gateway as a lightweight container for sidecar, internal API, or controlled lab deployments.

Policy-Based Rules

Expand YAML-driven rule definitions so teams can tune redaction behavior by workflow, sensitivity, and runtime context.