Disabling a user or downgrading their role terminates their live sessions, not just future logins

This evidences SOC 2 CC6.2, which requires that access is removed when no longer authorized: an auditor reads "removes access" to include in-flight sessions, not just the next login attempt. AI-generated apps fail this in a very specific way: the scaffold ships stateless JWTs with long lifetimes (next-auth defaults to 30 days) and an admin "ban user" route that flips a banned or is_active column, and nothing ever consults that column again until the token expires. The result is a deprovisioning gap where a fired employee, a compromised account, or a demoted admin keeps full live access for days or weeks after the org believes it was cut off. That gap is exactly what a SOC 2 auditor probes during the logical-access walkthrough ("show me what happens to an active session when you disable this user"), and it is the difference between a clean CC6.2 test and an exception in the report.

In every handler that disables a user or downgrades a role, revoke their live access in the same code path: call supabase.auth.admin.signOut(userId) (or clerkClient.sessions.revokeSession(...) per active session, or prisma.session.deleteMany({ where: { userId } }) for database sessions) immediately after the status write. If you are on stateless JWTs, either shorten the access-token lifetime to one hour or less and revoke refresh tokens on disable, or add a per-request check in middleware.ts that re-reads is_active and role from the database so stale sessions die on the next request.