Skip to content

Access control posture (cloud docs)

Purpose

Business-facing summary of how WorkWingman protects cloud documentation: who gets in, what they can see, and residual risk. No secrets, client IDs, or emails.

Control model

Control What it does
Cloudflare Access (OTP) Outer perimeter — must pass before the app
Google OAuth (app sign-in, PKCE) Proves identity inside the app
Per-document reader tiers Allowlist who may open each doc

Protected surfaces require both perimeter and app sign-in. Document access is fail-closed: not on the allowlist means no access.

Identity trust

  • Sign-in uses Google OAuth with PKCE (authorization code; no client secret in the client).
  • Token verification includes issuer, audience, and constant-time claim/signature comparison (hardened under WING-243, mutation-tested).
  • Residual engineering gap: full automated coverage of email_verified checks needs stubbed OAuth exchange (follow-up wt-cont-wing243). That does not by itself assert production misconfiguration.

Authorization model

  • Audiences are assigned per document via cloud-docs-manifest.json (examples of tier labels: yc-reviewer, team-test).
  • No allowlist entry → no document access.

Known operational risks

Session revocation lag

  • Allowlist is snapshotted when a session is created.
  • Revoking a person does not immediately end sessions already open; access ends after re-check / session refresh.
  • Tracked in WING-222 / WING-223 / WING-224 documentation.

Deploy ladder vs live-only settings (RT-3)

  • Seven reader-related settings exist in live only and are not declared on the environment ladder.
  • A ladder-based deploy can remove them and cause live sessions to be rejected.
  • Mitigation direction: declare and preserve those settings on the ladder before relying on ladder deploys for this surface.
  • TODO(verify): exact setting names (names only; never values).

Assurance status (as of 2026-07-30)

Assurance Status
Signed-out prod: access control functional Verified
Signed-out prod: PKCE configured Verified
Signed-in prod with real allowlisted Google account Deferred

Posture statement

Cloud docs are gated by a two-layer identity path and fail-closed, per-document reader tiers. Identity verification is hardened and partially mutation-tested. Main residual risks for decision-makers: revocation is not instant for live sessions, ladder deploys can strip live-only reader config, and full signed-in prod proof is still deferred.

Out of scope for this doc

  • Concrete allowlist members
  • OAuth client identifiers or secrets
  • Full env var inventory beyond the RT-3 hazard note