Access Control Policy

Owner: Backend Lead / Admin Last Edited: March 26, 2026 Last Reviewed: March 26, 2026

1. Access Layers

Prism has three distinct access layers:

2. Clerk Roles and Scope Mapping

Org roles

The canonical scope list is defined in go-backend/internal/domain/auth.go. The mapping from Clerk org_permissions to backend scopes is normalized in go-backend/internal/middleware/auth.go.

STRICT_CLERK_SCOPES=true must be set in production. When strict mode is on, a missing or empty org_permissions claim is treated as zero-scope (deny-by-default), not a fallback grant.

Infrastructure roles

3. MFA and SSO Requirements

MFA must be enforced for all accounts that have access to production systems:

• GitHub: require MFA for all org members (GitHub org settings → Authentication security)
• Clerk Dashboard: enable MFA on the Clerk admin account
• Supabase / cloud DB console: MFA enforced
• Cloudflare: MFA enforced
• Sentry: MFA enforced
• Render: MFA enforced

Single sign-on (SSO) is enforced for end users via Clerk. There is no direct username/password login to the Prism application.

4. Joiner Process (New Team Member)

1. Add to GitHub org with appropriate role (Write for engineers, Read for stakeholders).
2. Create Clerk account and assign to the correct Prism org with the correct role.
3. Provision access to any infrastructure systems (Supabase console, Cloudflare, monitoring) based on their role.
4. Do not share personal credentials. Each person gets their own account.
5. Record the provisioning date.

5. Mover Process (Role Change)

1. Update Clerk org role to the new role.
2. Update GitHub org role if it changed.
3. Update infrastructure access if it changed.
4. Verify old permissions are removed and new ones are active.
5. Record the change date.

6. Leaver Process (Off-boarding)

This must be completed on the day of departure, not deferred.

1. Clerk: remove user from all Prism orgs in the Clerk dashboard.
2. GitHub: remove from the GitHub org or revoke write access.
3. Infrastructure: revoke access to Supabase/RDS console, Cloudflare, Sentry, Render.
4. Prism API keys: revoke any API keys issued to the departing person or their services.
5. Infisical: revoke access to the Infisical project.
6. Slack webhooks / other integrations: rotate if the person had access to webhook URLs.
7. Shared credentials: rotate any shared secrets the person had access to.
8. Record the off-boarding date.

7. Access Review Cadence

A formal access review must be conducted monthly.

Monthly access review checklist:

• Export active Clerk org members and verify each has the correct role.
• Check GitHub org members — remove anyone no longer on the team.
• Review Prism API key list (GET /api/v1/api-keys) for each org — revoke stale or unrecognized keys.
• Review Infisical project members — remove anyone no longer on the team.
• Review infrastructure access (Supabase, Cloudflare, Sentry, Render) — remove stale accounts.
• Confirm MFA is still enforced on all systems.
• Record completion and any changes made.

Store access review records in docs/audit/access-reviews/.

8. API Key Policy

• API keys are org-scoped and must be created with the minimum set of scopes required.
• Keys must have an expiration date set (expires_in_days).
• Keys are stored hashed in the database — the plaintext key is only shown once at creation.
• Keys can be revoked at any time via DELETE /api/v1/api-keys/{id} (requires api_keys:manage scope).
• Do not put API keys in frontend code, browser environments, or version control.

9. Related Docs

• go-backend/internal/domain/auth.go — canonical scope definitions
• go-backend/internal/middleware/auth.go — scope normalization logic
• docs/backend/account-profile-onboarding-guide.md — Clerk claim expectations and role setup
• docs/security/secrets-management.md — secret rotation including API keys
• docs/security/incident-response.md — compromised account response