Privacy model

OngoingAI Gateway treats privacy as a storage and observability concern. It forwards provider traffic while limiting what is persisted in traces.

Choose this model when

• You need model usage, latency, and cost data for operations.
• You need controls for sensitive content in AI payloads.
• You need predictable privacy-risk controls in shared deployments.
• You need enough metadata for incident debugging without default body storage.

Privacy model summary

1. The gateway proxies requests to providers.
2. Sensitive auth headers are redacted before trace persistence.
3. Request and response bodies are not stored unless you enable body capture.
4. If body capture is enabled, storage redaction is the effective default.
5. Trace metadata is written asynchronously so proxy traffic is not blocked by trace storage.

Credential boundaries

• Provider credentials pass through to upstream providers for request handling.
• Provider credential values are redacted in stored trace headers.
• Gateway key headers are used for gateway auth and stripped before upstream forwarding.

What data is persisted

How redaction works

1. Body-capture middleware records headers and optional body copies with a max size cap (tracing.body_max_size).
2. Header redaction always applies to sensitive credential headers.
3. If tracing.capture_bodies=false, request and response bodies are not persisted.
4. If tracing.capture_bodies=true and mode is redact_storage, the gateway redacts the captured body copy before persistence.
5. Trace metadata records redaction details such as redaction_mode, redaction_applied, redaction_counts, and redaction_truncated.

PII mode behavior

• off: Body content is stored as captured when body capture is enabled.
• redact_storage: Body content is redacted before storage. Upstream forwarding remains unchanged.
• redact_upstream: Request body content is redacted before provider forwarding on proxied provider routes.
• block: Request is denied when configured detectors find protected content.

Stage and detector controls

• pii.stages.request_body and pii.stages.response_body control which body sides are redacted.
• pii.stages.request_headers and pii.stages.response_headers control whether custom header denylist entries are applied.
• pii.detectors controls pattern detectors such as email, phone, SSN, and token-like values.
• pii.body.key_denylist redacts JSON fields by key name.
• pii.replacement.format and pii.replacement.hash_salt control placeholder format and hashing inputs.
• pii.scopes[] applies scoped overrides by org/workspace/key/provider/route. The most specific matching scope is selected.

Failure behavior

• In redact_storage mode, if body redaction fails, the gateway drops body persistence for that trace and continues proxy traffic.
• In redact_upstream and block, the gateway fails closed if policy evaluation cannot complete on the request body, returning 503.
• In block, if detection succeeds and protected content is found, the request is denied with 403.
• When body capture is truncated by size limit, metadata includes redaction_truncated=true when redaction is active.
• If configuration is invalid, startup fails fast during ongoingai serve or ongoingai config validate.

Concrete example

Given this captured request body:

{"email":"alex@example.com","api_key":"sk_test_1234567890"}

With body capture enabled and pii.mode=redact_storage, stored content becomes placeholder values:

{"email":"[EMAIL_REDACTED:...]","api_key":"[FIELD_REDACTED:...]"}

The trace metadata also records redaction context:

• redaction_mode: redact_storage
• redaction_applied: true
• redaction_counts: {...}

Next steps

• Learn operational controls
• Review trace data structure
• Review configuration fields