diff --git a/‎.changeset/20580-explain-removed-member.md‎
Lines changed: 17 additions & 0 deletions b/‎.changeset/20580-explain-removed-member.md‎
Lines changed: 17 additions & 0 deletions
diff --git a/‎packages/core/src/security/index.ts‎
Lines changed: 3 additions & 0 deletions b/‎packages/core/src/security/index.ts‎
Lines changed: 3 additions & 0 deletions
diff --git a/‎packages/core/src/security/resolve-authz-context.test.ts‎
Lines changed: 33 additions & 1 deletion b/‎packages/core/src/security/resolve-authz-context.test.ts‎
Lines changed: 33 additions & 1 deletion
diff --git a/‎packages/core/src/security/resolve-authz-context.ts‎
Lines changed: 32 additions & 3 deletions b/‎packages/core/src/security/resolve-authz-context.ts‎
Lines changed: 32 additions & 3 deletions
diff --git a/‎packages/plugins/plugin-security/src/explain-engine.ts‎
Lines changed: 4 additions & 0 deletions b/‎packages/plugins/plugin-security/src/explain-engine.ts‎
Lines changed: 4 additions & 0 deletions
@@ -0,0 +1,17 @@
+---
+'@objectstack/plugin-security': patch
+'@objectstack/core': minor
+---
+
+fix(plugin-security): `security/explain` resolves the user it explains in the organization enforcement resolves them in, so a member whose membership in the caller's organization has ended is no longer explained holding that organization's grants (#20580)
+
+When an administrator explains another user, the explanation is computed in the administrator's own organization. Enforcement does one more thing for that same user first: under a walled tenancy posture (`isolated` or `group`), it drops an organization claim that no current membership backs, and the user resolves with no active organization, so only their global grants apply. The explainer skipped that check. For a user whose membership in the administrator's organization had ended, the explanation listed that organization's grants, and the verdicts they decide, while enforcement applied none of them.
+
+The explainer now asks the same check before it resolves the user, and resolves them where it says. `@objectstack/core` exports that check as `vetOrganizationClaim(claimedOrganizationId, accessibleOrgIds, tenancyPosture)`. It returns the claimed organization while a current membership backs it or while no wall is enforced, and `undefined` once the claim is dropped. `resolveAuthzContext` asks the same function for a session's claim, so the two cannot disagree. This is a new export with no behaviour change to `resolveAuthzContext`.
+
+Unchanged:
+
+- Enforcement admits and refuses exactly what it did before.
+- A current member's explanation.
+- The `single` posture, where no claim is dropped on either side.
+- Explaining yourself, and a caller with no active organization.
@@ -137,6 +137,9 @@ export {
   // surface that only knows a user id asks this instead of re-reading
   // `sys_*_permission_set` — the prohibition resolve-authz-context.ts states.
   hasPlatformAdminStanding,
+  // [#20580] The session arm's membership check (#15409 ruling B), so the
+  // permission explainer resolves the user it explains through the same one.
+  vetOrganizationClaim,
   resolveLocalizationContext,
   type ResolvedAuthzContext,
   type ResolveAuthzInput,
 
@@ -1,7 +1,7 @@
 // Copyright (c) 2025 ObjectStack. Licensed under the Apache-2.0 license.
 
 import { describe, it, expect, vi, beforeEach, afterEach } from 'vitest';
-import { hasPlatformAdminStanding, resolveAuthzContext, resolveUserAuthzGrants, resolveLocalizationContext } from './resolve-authz-context.js';
+import { hasPlatformAdminStanding, resolveAuthzContext, resolveUserAuthzGrants, resolveLocalizationContext, vetOrganizationClaim } from './resolve-authz-context.js';
 import { POSTURE_RANK } from './posture-ladder.js';
 import { hashApiKey } from './api-key.js';
 import type { AuthzPosture } from '@objectstack/spec/security';
@@ -1832,6 +1832,38 @@ describe('[#15409] a session organization claim that no membership backs', () =>
   });
 });
 
+/**
+ * [#20580] The session arm's check, as the one exported function a second
+ * reader (plugin-security's permission explainer) asks about the user it
+ * explains. The session arm's own behaviour is pinned end to end above; this
+ * block pins the function's contract, so a change to either reader's answer
+ * goes through here.
+ */
+describe('[#20580] vetOrganizationClaim — the organization a claim resolves in', () => {
+  const HELD = ['org_beta', 'org_gamma'];
+
+  it('walled (`isolated`, `group`): a claim no current membership backs is dropped', () => {
+    expect(vetOrganizationClaim('org_alpha', HELD, 'isolated')).toBeUndefined();
+    expect(vetOrganizationClaim('org_alpha', HELD, 'group')).toBeUndefined();
+    expect(vetOrganizationClaim('org_alpha', [], 'isolated')).toBeUndefined();
+  });
+
+  it('walled: a claim a current membership backs stands as made', () => {
+    expect(vetOrganizationClaim('org_beta', HELD, 'isolated')).toBe('org_beta');
+    expect(vetOrganizationClaim('org_gamma', HELD, 'group')).toBe('org_gamma');
+  });
+
+  it('no wall (`single`, or no posture supplied): the claim stands whatever the memberships', () => {
+    expect(vetOrganizationClaim('org_alpha', HELD, 'single')).toBe('org_alpha');
+    expect(vetOrganizationClaim('org_alpha', [], undefined)).toBe('org_alpha');
+  });
+
+  it('no claim resolves in no organization', () => {
+    expect(vetOrganizationClaim(undefined, HELD, 'isolated')).toBeUndefined();
+    expect(vetOrganizationClaim('', HELD, 'single')).toBeUndefined();
+  });
+});
+
 /**
  * [#20515] A resolution with NO active organization applies only the GLOBAL
  * grants (`organization_id` null). A grant scoped to an organization applies
 
@@ -529,12 +529,13 @@ export async function resolveAuthzContext(input: ResolveAuthzInput): Promise<Res
   // Session-only by construction: an admitted API key sets `userId`, which
   // makes the session branch above unreachable, so a non-empty `tenantId` here
   // with no `keyPrincipal` can only have come from the session claim.
+  //
+  // [#20580] The check itself is {@link vetOrganizationClaim}, so the
+  // permission explainer asks the same question about the user it explains.
   if (
     !keyPrincipal
     && tenantId
-    && input.tenancyPosture
-    && postureEnforcesWall(input.tenancyPosture)
-    && !grants.accessible_org_ids.includes(tenantId)
+    && vetOrganizationClaim(tenantId, grants.accessible_org_ids, input.tenancyPosture) === undefined
   ) {
     // [#15256 / 2A, mirrored] The one decision point where the drop is decided.
     warnSessionOrganizationClaimDropped({
@@ -565,6 +566,34 @@ export async function resolveAuthzContext(input: ResolveAuthzInput): Promise<Res
   return ctx;
 }
 
+/**
+ * [#15409 — maintainer ruling 2026-09-05, option B] The organization a
+ * principal that CLAIMS `claimedOrganizationId` is resolved in: the claim
+ * itself while a current membership backs it, `undefined` once it does not.
+ *
+ * This is the session arm of {@link resolveAuthzContext}, as one function.
+ * Under a wall-enforcing posture (`isolated`, `group`) a claim on an
+ * organization absent from `accessibleOrgIds` (the principal's
+ * {@link UserAuthzGrants.accessible_org_ids}, which does not depend on the
+ * organization the grants were resolved in) is dropped, and the principal
+ * resolves with NO active organization. Under `single`, or with no posture
+ * supplied, there is no wall and the claim stands as made.
+ *
+ * [#20580] A second reader asks it: the permission explainer, about the user
+ * it explains in the caller's organization. That is how `security/explain`
+ * resolves that user in the organization enforcement would resolve them in.
+ * ⛔ Nothing else spells this rule — a caller that needs it calls this.
+ */
+export function vetOrganizationClaim(
+  claimedOrganizationId: string | undefined,
+  accessibleOrgIds: readonly string[],
+  tenancyPosture: TenancyPosture | undefined,
+): string | undefined {
+  if (!claimedOrganizationId) return undefined;
+  if (!tenancyPosture || !postureEnforcesWall(tenancyPosture)) return claimedOrganizationId;
+  return accessibleOrgIds.includes(claimedOrganizationId) ? claimedOrganizationId : undefined;
+}
+
 /** The authorization grants a KNOWN user holds — a subset of {@link ResolvedAuthzContext}. */
 export interface UserAuthzGrants {
   positions: string[];
 
@@ -568,6 +568,10 @@ async function collectGrantProvenance(
  * very resolution that kept a removed member's grants. Each caller passes the
  * organization it is explaining in — the live principal's for a delegator
  * ({@link resolveDelegatorContext}), the caller's own for the explain API.
+ * [#20580] The explain API passes the caller's organization only once
+ * `vetOrganizationClaim` (`@objectstack/core`) has let it stand for the
+ * explained user, as enforcement does for that user's session claim: this
+ * function passes on what it is handed and vets nothing itself.
  * Omitted, the context is the user with NO active organization. The returned
  * context still carries no `tenantId` of its own; a caller that needs one sets
  * it, as {@link resolveDelegatorContext} does.