- Shipped
- August 3, 2026 at 2:51 AM UTC
- Author
- Kamo
- Commit
- a2390e5
Recording playback left no trace. A recorded call is the densest PHI the platform stores — the unredacted conversation — and "who listened to this call" was unanswerable, which is the first question a §164.402 breach assessment asks. Wires CallRecordingAuditor into every read that discloses it: - GET /recordings/{id}/audio CALL_RECORDING / DOWNLOAD - GET **************** CALL_RECORDING / DOWNLOAD - GET /recordings/{id} CALL_RECORDING + TRANSCRIPT / VIEW - GET **************** CALL_RECORDING / DOWNLOAD - GET /instances/{id}/voicemails TRANSCRIPT / LIST, per row The transcript is the one that hides. It is not a media download; it rides inside the metadata JSON and inside every voicemail row, and it is the same PHI as the audio in a form that greps. It gets its own event because an accounting of disclosures is assembled per resource. Byte serving fails closed, so PhiAuditAvailabilityAdvice turns an unloggable read into a 503 rather than a 500 — the request was fine, we decoderd to serve PHI we could not account for. Refusals are recorded too; probing is what detection looks for. Also closes an authorization gap found while wiring this: POST /recordings/lookup took an instanceId from the request body and never checked the caller's org owns it, so it resolved another tenant's provider call ids to their recording ids. Every other instance-scoped endpoint in the service already goes through findByIdAndOrgId; this one now does too. Recording playback authorization is left as-is and documented in place: org ownership is the only check, so any member can play back any recording in their org. Narrowing it means deciding whether "own extension" is the boundary and which right lifts it — that is a product decision, not a guess to make here, and every access is at least recorded now.