ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
1e0f21365b
TenantAtlas/specs/276-support-access-governance/research.md
ahmido 1e0f21365b PR: 276-support-access-governance → platform-dev (#332) 
Automated PR created via MCP by Copilot on user request: "pr gegen platform-dev".

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #332
2026-05-05 21:54:26 +00:00

4.7 KiB
Raw Blame History

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.