# Research: Enterprise Access Boundary & Support Access Governance v1

**Date**: 2026-05-05  
**Branch**: `276-support-access-governance`

## Decision 1: Keep support access workspace-scoped and tied to repo-real support seams

- **Decision**: V1 support access is workspace-scoped and only governs two current repo-real scopes: `audit_view` and `workspace_recovery`.
- **Rationale**: The repository already has workspace detail, workspace settings, audit history, break-glass, and owner-repair seams. Those seams are enough to deliver customer-safe support governance without inventing a broad delegated admin bridge.
- **Alternatives considered**:
  - Full impersonation or delegated admin browsing: rejected because the repo has no current bounded bridge for that and the slice would become an IAM project.
  - Keep break-glass as the only support mechanism: rejected because it is global, session-based, and not customer-visible enough for ordinary support access.

## Decision 2: Use one workspace-owned grant history, not session-only state

- **Decision**: Persist support-access lifecycle in a new workspace-owned `support_access_grants` table.
- **Rationale**: Support access now needs approval lineage, expiry, reason capture, and customer-visible history that outlives one PHP session.
- **Alternatives considered**:
  - Session-only state layered onto `BreakGlassSession`: rejected because approval and workspace-visible history would drift or disappear.
  - Audit-log-only reconstruction with no first-class entity: rejected because lifecycle and dedupe rules would become hard to reason about and hard to gate correctly.

## Decision 3: Make `workspace_recovery` require both support access and break-glass

- **Decision**: The existing `RepairWorkspaceOwners` action requires both an active `workspace_recovery` grant for the target workspace and active break-glass.
- **Rationale**: This keeps ordinary support access and emergency recovery visibly separate while preventing the owner-repair utility from relying on platform capability plus break-glass alone.
- **Alternatives considered**:
  - Support access alone enables recovery: rejected because it would collapse ordinary support and emergency recovery.
  - Break-glass alone enables recovery: rejected because it preserves today’s governance gap.

## Decision 4: Reuse existing system and admin surfaces instead of adding a new support console

- **Decision**: Reuse `ViewWorkspace`, `WorkspaceSettings`, `AuditLog`, and `AccessLogs`.
- **Rationale**: These surfaces already own workspace detail, owner approval, customer-visible history, and system security history. A new support console would duplicate navigation and create a second control plane.
- **Alternatives considered**:
  - New support-access resource or page family: rejected because it would duplicate existing detail and history semantics.
  - Approval through email or out-of-band workflow only: rejected because it would leave the product without one inspectable approval truth.

## Decision 5: Keep approval optional only where the risk profile changes

- **Decision**: `audit_view` may auto-activate for authorized platform operators. `workspace_recovery` requires workspace-owner approval when owners exist, and uses an explicit waiver path only when the workspace is ownerless and break-glass is already active.
- **Rationale**: This keeps the slice narrow while still giving the high-risk recovery path the stronger human approval boundary it needs.
- **Alternatives considered**:
  - Require approval for every scope: rejected because it would add friction to low-risk history inspection and overcomplicate the first slice.
  - Never require approval: rejected because recovery support would remain too close to today’s emergency bypass.

## Decision 6: Export customer-visible history from the existing admin audit page

- **Decision**: Support-access export belongs on the current admin audit-log surface with a support-access filter preset.
- **Rationale**: The admin audit log is already the customer-visible history surface and already understands workspace-scoped event inspection.
- **Alternatives considered**:
  - Export from the system access-log page only: rejected because that stays platform-side and does not satisfy customer-visible history.
  - Add a dedicated support-history export page: rejected because it would duplicate the existing audit-history family.

## Final Research Outcome

- Current-release truth justifies one workspace-owned support-access grant history.
- The slice stays on two repo-real support scopes and explicitly defers impersonation.
- Recovery becomes the one place where support access and break-glass must both be present.
- Existing detail, settings, and history surfaces are sufficient for the first governed package.