PII redaction 502 (fail-closed)

What you’ll see


{
  "error": "Upstream request failed",
  "detail": "Response could not be safely returned",
  "correlation_id": "...",
  "report_hint": { "url": "...", "suggested_payload": { /* ... */ } }
}

HTTP status 502. The upstream SaaS call may have succeeded — the problem is downstream of that, in the PII redaction stage.

In the dashboard’s Audit log, the corresponding row has:

result = "error"
metadata.reason = "pii_redaction_failed"
metadata.pii_error populated with the Presidio error kind (timeout, network, http, or breaker_open)
pii_redacted = false, pii_detected = null

Why

When your org has the PII Redaction beta flag enabled (toggled by superadmin under /superadmin), every successful upstream response is routed through Microsoft Presidio (analyzer + anonymizer) before being returned to the agent. The agent’s per-platform visibility map decides which entities are kept, masked, replaced, redacted, or hashed.

If Presidio errors — timeout, network failure, 5xx response, or the process-wide circuit breaker has opened after 5 consecutive failures — the proxy fails closed. The agent gets a generic 502 with no upstream body. No unredacted content leaks when redaction breaks.

This is by design. If redaction can’t be guaranteed, the only safe choice is to withhold the response.

Fix

Confirm the beta is intentionally on


Superadmin → Per-Org Beta Flags → search your org's owner email

If pii_redaction_enabled = false, the beta is off — and a 502 with this signature shouldn’t be possible. File a bug.

If on and you didn’t expect that, turn it off. The next call will skip Presidio entirely (zero added latency, no fail-closed path).

Check Presidio health

The proxy logs the Presidio error kind in metadata.pii_error:

Kind	Meaning	Fix
`timeout`	Analyzer took >2s or anonymizer took >1s	Often a spaCy cold start. Confirm `minReplicas: 1` on both Container Apps (it should be, per the prod scale config)
`network`	DNS / TCP / TLS failure reaching the internal FQDN	Check both Presidio Container Apps are running; check the env vars `PRESIDIO_ANALYZER_URL` and `PRESIDIO_ANONYMIZER_URL` on the proxy
`http`	Presidio returned 4xx or 5xx	Check the Presidio container logs in Azure
`breaker_open`	5 consecutive Presidio failures opened the in-process breaker	The breaker auto-resets after 30 seconds. If it keeps opening, root-cause one of the kinds above

Confirm the agent’s claim makes sense

The fail-closed only fires when the agent has a per-platform visibility claim for the platform being called. If the agent has no claim, the proxy skips Presidio entirely and the response goes through unredacted (the “no claim” skip reason). Check Agent detail → PII Visibility to confirm the platform’s persona is what you expect.

Two circuit breakers, not one

There’s a separate circuit breaker for the agent itself (circuit_breaker_open) that auto-suspends an agent after 3 consecutive failures. PII-redaction failures count toward that breaker too. So a sustained Presidio outage will eventually suspend agents that hit it repeatedly.

The Presidio circuit breaker (in-process, process-wide, 5-failure threshold, 30-second cooldown) is a separate mechanism that protects the proxy from amplifying a Presidio outage by repeatedly hammering a dead service.