ADR-010: x-internal-secret authentication, mvs-auth integration deferred

Status

Accepted (2026-05-28). Revisit when mvs-auth plan lands.

Context

mvs-pay-extensions is consumed by multiple repos (mvs-pay UI, healthos, mvs-c2). Per-user authentication via mvs-auth would propagate user identity through to PHI audit trails. mvs-auth is on a separate plan.

Decision

Use a single shared MVS_PAY_EXTENSIONS_INTERNAL_SECRET for service-to-service trust. Per-user identity is not propagated. phiAudit.logAccess() records userId: null until mvs-auth lands.

Consequences

  • Trust boundary risk: an upstream compromise has full payments blast radius.
  • Mitigated by rate-limit middleware (Phase 3), WAF (external), and quarterly secret rotation.
  • When mvs-auth lands, every route adds JWT validation alongside x-internal-secret. Decommission x-internal-secret over a 90-day overlap window once consumers cut over.

Alternatives considered

  • Block on mvs-auth: rejected — would delay launch indefinitely.
  • Build mvs-auth-equivalent JWT validation in mvs-pay: rejected — duplicates work and creates a parallel auth surface.