@@ -0,0 +1,17 @@
+---
+'@objectstack/plugin-security': patch
+---
+
+fix(plugin-security)!: a delegate can neither capture nor evict a direct grant beyond its scope
+
+Clause-②: no (narrowing) — an edit that points a direct permission-set grant at another user is judged on both holders it touches, the user it takes the grant from and the user it gives the grant to, and an edit that re-names a stored grant's set is judged on the set it takes away as well as the set it grants, so a delegated administrator no longer moves a grant away from a holder outside its subtree or from a holder it cannot read, nor re-names a stored grant of a set outside its allowlist. Nothing is widened: no export, error code or status is added.
+Metadata-protocol: none
+
+<!-- adr-0087: not-required (no-migration-prescription) No key of any schema is added, removed, renamed or re-shaped, and no export of the package entry changes: a direct grant keeps its shape and meaning, each holder an edit touches is judged as a target user already is, and the set an edit takes away is judged as the removal of that grant already judges it. There is nothing for a migration to rewrite and no tombstone. -->
+
+**BREAKING** accept-set narrowing in the delegated-administration gate (`@objectstack/plugin-security`), only for a delegated administrator editing a stored direct grant's holder or set.
+
+- **Rule.** A delegate can neither capture nor evict a direct grant beyond its scope (ADR-0090 D12). A delegated write on a direct permission-set grant is judged on every holder and every set it touches. An edit that points a stored grant at another user is judged on the holder it takes the grant from and on the holder it gives the grant to, each exactly as the gate judges a target user — through the caller's own read, and inside the subtree only through one of the subtree's business units. An edit that re-names a stored grant's permission set is judged on the set it takes away exactly as the removal of that grant judges it — the allowlist, the security catalog and strict containment — beside the set it re-names the grant to, judged as before.
+- **What a caller sees.** An edit with either holder outside the subtree, or a holder the caller cannot read, answers `403 DELEGATION_SCOPE_VIOLATION`, with the sentence and details of every target outside the subtree, whichever end it is. A re-name away from a set outside the allowlist answers the refusal the removal of that grant answers — `403 DELEGATION_SCOPE_VIOLATION`, "permission set '…' is not in the scope's allowlist", with that set in its details — and a re-name away from a set whose removal is refused on any other ground gets that refusal. The stored holder and the stored set are named only when the caller reads them. A stored grant that names no holder is moved only by a tenant-level administrator (`403 PERMISSION_DENIED`).
+- **Unchanged.** The judgment of the set an edit points a grant at; an edit that keeps both the holder and the set, an insert and a removal; a tenant-level administrator's writes; an organization administrator's writes, whose right creates and removes a grant and never edits one in place.
+- **Who moves.** A delegate can no longer move a direct grant away from a holder outside its subtree, nor re-name a stored grant of a set outside its allowlist. A holder it cannot read counts as outside its subtree, and a grant it could not remove it cannot re-name. Such a grant is moved or re-named by a tenant-level administrator, or removed and granted anew by an administrator whose boundary covers it.
@@ -72,8 +72,8 @@ set, and the gate resolves the name in the security catalog. The gate's rules:
 | Rule | Effect |
 |---|---|
 | Tenant admins pass through | The superuser wildcard reaches the ordinary CRUD/RLS checks — delegation constrains *delegates*, not HQ |
-| Subtree anchoring | Assignments a delegate creates must be anchored (`sys_user_position.business_unit_id`) inside their subtree, and the target user must sit inside it |
-| Allowlist, no self-escalation | Every set reached by the write — bound to the assigned position, or granted directly — must be on `assignablePermissionSets`. Granting an un-allowlisted set is refused **for anyone, including the delegate themselves** |
+| Subtree anchoring | Assignments a delegate creates must be anchored (`sys_user_position.business_unit_id`) inside their subtree, and the target user must sit inside it. A direct grant's holder must too, at both ends of an edit that moves the grant to another user: a delegate can neither capture nor evict a direct grant beyond its subtree |
+| Allowlist, no self-escalation | Every set reached by the write — bound to the assigned position, or granted directly — must be on `assignablePermissionSets`. Granting an un-allowlisted set is refused **for anyone, including the delegate themselves**. An edit that re-names a stored direct grant is judged on the set it takes away as well, exactly as removing that grant is: a delegate can neither capture nor evict a direct grant beyond its scope |
 | Action flag | `manageAssignments` gates the assignment rows — `sys_user_position`, and direct `sys_user_permission_set` grants — and is the scope's only action right. A position's sets are part of its definition and a permission set is a definition: both are written through the metadata door, which admits a `manage_metadata` holder (the platform operator under `group` or `isolated`) and reads no `adminScope` (ADR-0131 D3). The scope's former `manageBindings` and `authorEnvironmentSets` named the retired `sys_position_permission_set` and `sys_permission_set` rows, admitted no write once those objects were gone, and are retired: the schema refuses both with the fix |
 | Strict containment | Granting a set that itself carries an `adminScope` — assigning a position that distributes it, or granting it directly — requires a held scope that **strictly contains** it: the same root, no wider subtree, `manageAssignments` only if yours has it, an allowlist inside yours, and smaller on at least one of those. Handing your own exact scope to a peer is refused (no lateral propagation) |
 | Single-row writes | Delegates write single rows by id only — a broad filter-write cannot be boundary-checked |
 
@@ -2138,3 +2138,212 @@ describe('[ADR-0090 D12] a delegated scope covers a user for the explain doors o
     }
   });
 });
+
+// ── [ADR-0090 D12] A delegate can neither capture nor evict a direct grant
+//    beyond its subtree. An update that points a stored grant at another user
+//    touches two holders — the user it takes the grant from and the user it
+//    gives the grant to — and each is judged as a target user is judged
+//    everywhere (above): through the caller's own read, inside the subtree only
+//    through one of its business units. A holder outside, at either end, is
+//    refused with the one scope-violation answer, the same whichever end it is.
+
+/**
+ * The two ends of an update pointing a stored grant at another user, each the
+ * gate's own `assert` by `context` (the delegate's unless given): `from` moves
+ * `TARGET`'s stored grant to `u_east_1`, a holder inside the subtree the
+ * caller reads; `to` moves `u_east_1`'s stored grant to `TARGET`.
+ */
+const MOVE_ENDS = {
+  from: (harness: TargetHarness, context = harness.ctxOf('delegate')) => {
+    harness.tables.sys_user_permission_set = [{ id: 'g_target', user_id: TARGET, permission_set: 'sales_user' }];
+    return harness.gate.assert({
+      object: 'sys_user_permission_set', operation: 'update', data: { id: 'g_target', user_id: 'u_east_1' }, context,
+    });
+  },
+  to: (harness: TargetHarness, context = harness.ctxOf('delegate')) => {
+    harness.tables.sys_user_permission_set = [{ id: 'g_east', user_id: 'u_east_1', permission_set: 'sales_user' }];
+    return harness.gate.assert({
+      object: 'sys_user_permission_set', operation: 'update', data: { id: 'g_east', user_id: TARGET }, context,
+    });
+  },
+} as const;
+
+/** The one answer a holder outside the subtree gets, at either end of the move. */
+const OUTSIDE_HOLDER =
+  /^\[Security\] Outside your delegated scope: delegated 'update' on sys_user_permission_set rejected — target user 'u_target' is outside the delegated subtree \(scope from 'sub_admin'\)\.$/;
+
+describe('[ADR-0090 D12] a delegate can neither capture nor evict a direct grant beyond its subtree: an update that points a stored grant at another user is judged on both holders', () => {
+  it(`moving a grant FROM a holder outside the subtree TO a holder inside is refused, for each of the ${TARGET_STATES.length} target states, with one answer`, async () => {
+    const answers: Array<ReturnType<typeof answerOf>> = [];
+    for (const state of TARGET_STATES) answers.push(answerOf(await refusalOf(() => MOVE_ENDS.from(harnessWith(state)))));
+    for (const [i, answer] of answers.entries()) expect(answer, TARGET_STATES[i]).toEqual(answers[0]);
+    const err = await refusalOf(() => MOVE_ENDS.from(harnessWith('a user whose business unit is outside the subtree')));
+    expectScopeViolation(err, 'sys_user_permission_set', OUTSIDE_HOLDER);
+    expect(err.details).toEqual({ operation: 'update', object: 'sys_user_permission_set', permissionSet: 'sales_user' });
+  });
+
+  it('moving a grant FROM a holder inside the subtree whom the caller cannot read is refused', async () => {
+    const err = await refusalOf(() => MOVE_ENDS.from(harnessWith(UNREADABLE_INSIDE)));
+    expectScopeViolation(err, 'sys_user_permission_set', OUTSIDE_HOLDER);
+  });
+
+  it('moving a grant TO a holder outside the subtree is refused, as before', async () => {
+    for (const state of TARGET_STATES) {
+      expectScopeViolation(await refusalOf(() => MOVE_ENDS.to(harnessWith(state))), 'sys_user_permission_set', OUTSIDE_HOLDER);
+    }
+  });
+
+  it('the refusal is the same whichever end is outside: class, code, status, message, details and the REST envelope', async () => {
+    for (const state of TARGET_STATES) {
+      expect(answerOf(await refusalOf(() => MOVE_ENDS.from(harnessWith(state)))), state)
+        .toEqual(answerOf(await refusalOf(() => MOVE_ENDS.to(harnessWith(state)))));
+    }
+  });
+
+  it('CONTROL: moving a grant between two holders inside the subtree, both read by the caller, is admitted at either end', async () => {
+    for (const [end, move] of Object.entries(MOVE_ENDS)) {
+      await expect(move(harnessWith(READABLE_INSIDE)), end).resolves.toBeUndefined();
+    }
+  });
+
+  it("both holders are asked of the caller's own read, under the write's own context", async () => {
+    for (const [end, move] of Object.entries(MOVE_ENDS)) {
+      const harness = harnessWith(READABLE_INSIDE);
+      const context = harness.ctxOf('delegate');
+      await move(harness, context);
+      expect(harness.callerUserReads, end).toEqual([context, context]);
+      for (const read of harness.callerUserReads) expect(read, end).toBe(context);
+    }
+  });
+
+  it('a stored grant that names no holder is moved by no delegate: only a tenant admin may move it', async () => {
+    const harness = harnessWith(READABLE_INSIDE);
+    harness.tables.sys_user_permission_set = [{ id: 'g_none', user_id: null, permission_set: 'sales_user' }];
+    const move = (context: any) => harness.gate.assert({
+      object: 'sys_user_permission_set', operation: 'update', data: { id: 'g_none', user_id: 'u_east_1' }, context,
+    });
+    const err = await refusalOf(() => move(harness.ctxOf('delegate')));
+    expectOpaqueDenial(err, 'sys_user_permission_set');
+    expect(err.message).toMatch(/the existing grant names no target user — only a tenant admin may move it/);
+    await expect(move(harness.ctxOf('tenant_admin'))).resolves.toBeUndefined();
+  });
+
+  it('CONTROL: a tenant-level administrator moves the grant whichever end is outside, and asks the read nothing', async () => {
+    for (const state of TARGET_STATES) {
+      for (const [end, move] of Object.entries(MOVE_ENDS)) {
+        const harness = harnessWith(state);
+        await expect(move(harness, harness.ctxOf('tenant_admin')), `${end} · ${state}`).resolves.toBeUndefined();
+        expect(harness.callerUserReads, `${end} · ${state}`).toEqual([]);
+      }
+    }
+  });
+});
+
+// ── [ADR-0090 D12] … and on the set axis. An update that re-names a stored
+//    direct grant's set takes that set away from its holder, so the set it
+//    takes away is judged exactly as the removal of that grant judges it — the
+//    allowlist, the catalog and strict containment, with the same reasons,
+//    sentences and details — and named only when the caller reads it (ruling
+//    of record 6649064874). A grant the delegate could not remove it cannot
+//    re-name either; the set it re-names the grant TO is judged as before.
+
+/**
+ * A delegate over `east` allowlisting `sales_user`, `support_user` and
+ * `west_admin` — the last carrying an adminScope over `west`, which the
+ * delegate's own scope does not strictly contain — and three stored grants of
+ * `u_east_1`, a holder inside the subtree the caller reads: `g_fin` of
+ * `finance_admin` (outside the allowlist), `g_west` of `west_admin`, and
+ * `g_retired` of a name the catalog does not hold. `masked` serves the
+ * caller's read of a grant without its `permission_set`.
+ */
+function renameHarness({ masked = false } = {}) {
+  const harness = makeHarness();
+  harness.tables.sys_permission_set.push(
+    { id: 'ps_support', name: 'support_user' },
+    { id: 'ps_west', name: 'west_admin', admin_scope: JSON.stringify({ ...EAST_SCOPE, businessUnit: 'west' }) },
+  );
+  harness.tables.sys_user_permission_set = [
+    { id: 'g_fin', user_id: 'u_east_1', permission_set: 'finance_admin' },
+    { id: 'g_west', user_id: 'u_east_1', permission_set: 'west_admin' },
+    { id: 'g_retired', user_id: 'u_east_1', permission_set: 'sales_user_retired' },
+    { id: 'g_sales', user_id: 'u_east_1', permission_set: 'sales_user' },
+  ];
+  const scope = { ...EAST_SCOPE, assignablePermissionSets: ['sales_user', 'support_user', 'west_admin'] };
+  const gate = new DelegatedAdminGate({
+    ql: harness.ql,
+    resolveSets: async (context: any) => context?.principal === 'tenant_admin'
+      ? harness.SETS.tenant_admin
+      : [{ name: 'east_admin', objects: {}, adminScope: scope }] as any[],
+  });
+  if (masked) {
+    const { findOne } = harness.ql;
+    harness.ql.findOne = async (object: string, opts: any) => {
+      const row = await findOne.call(harness.ql, object, opts);
+      if (object !== 'sys_user_permission_set' || opts?.context?.isSystem || !row) return row;
+      const { permission_set: _hidden, ...rest } = row;
+      return rest;
+    };
+  }
+  const as = (principal: string) => harness.ctxOf(principal);
+  const rename = (id: string, permission_set: string, context = as('delegate')) => gate.assert({
+    object: 'sys_user_permission_set', operation: 'update', data: { id, permission_set }, context,
+  });
+  const remove = (id: string, context = as('delegate')) => gate.assert({
+    object: 'sys_user_permission_set', operation: 'delete', options: { where: { id } }, context,
+  });
+  return { ...harness, gate, as, rename, remove };
+}
+
+/** A refusal's answer with its operation word spelled out of it: what a re-name and a removal must share. */
+const operationFree = (answer: ReturnType<typeof answerOf>) =>
+  JSON.parse(JSON.stringify(answer).replace(/'(update|delete)'/g, "'OP'").replace(/"(update|delete)"/g, '"OP"'));
+
+describe('[ADR-0090 D12] a delegate can neither capture nor evict a direct grant beyond its scope: an update that re-names a stored grant is judged on the set it takes away as the removal of that grant is', () => {
+  it('re-naming a grant FROM a set outside the allowlist TO an allowlisted one is refused, with the answer the removal of that grant gets', async () => {
+    const r = renameHarness();
+    const renamed = await refusalOf(() => r.rename('g_fin', 'sales_user'));
+    expectScopeViolation(renamed, 'sys_user_permission_set',
+      /^\[Security\] Outside your delegated scope: delegated 'update' on sys_user_permission_set rejected — permission set 'finance_admin' is not in the scope's allowlist \(scope from 'east_admin'\)\.$/);
+    expect(renamed.details).toEqual({ operation: 'update', object: 'sys_user_permission_set', permissionSet: 'finance_admin' });
+    expect(operationFree(answerOf(renamed))).toEqual(operationFree(answerOf(await refusalOf(() => r.remove('g_fin')))));
+  });
+
+  it('the removal\'s other refusals hold for a re-name too: a set the delegate\'s scope does not strictly contain, and a name the catalog does not hold', async () => {
+    const r = renameHarness();
+    for (const id of ['g_west', 'g_retired']) {
+      const renamed = await refusalOf(() => r.rename(id, 'sales_user'));
+      expectOpaqueDenial(renamed, 'sys_user_permission_set');
+      expect(operationFree(answerOf(renamed)), id).toEqual(operationFree(answerOf(await refusalOf(() => r.remove(id)))));
+    }
+    expect((await refusalOf(() => r.rename('g_west', 'sales_user'))).message).toMatch(/granting set 'west_admin' would hand out an adminScope not strictly contained by yours/);
+    expect((await refusalOf(() => r.rename('g_retired', 'sales_user'))).message).toMatch(/permission set 'sales_user_retired' is not in the security catalog/);
+  });
+
+  it('a caller that cannot read the stored set is told the same refusal without its name, as the removal is', async () => {
+    const r = renameHarness({ masked: true });
+    const renamed = await refusalOf(() => r.rename('g_fin', 'sales_user'));
+    expectScopeViolation(renamed, 'sys_user_permission_set', /the grant's permission set is not in the scope's allowlist/);
+    expect(renamed.message).not.toMatch(/finance_admin/);
+    expect(renamed.details).toEqual({ operation: 'update', object: 'sys_user_permission_set' });
+    expect(operationFree(answerOf(renamed))).toEqual(operationFree(answerOf(await refusalOf(() => r.remove('g_fin')))));
+  });
+
+  it('re-naming a grant TO a set outside the allowlist is refused, as before', async () => {
+    const r = renameHarness();
+    const err = await refusalOf(() => r.rename('g_sales', 'finance_admin'));
+    expectScopeViolation(err, 'sys_user_permission_set', /permission set 'finance_admin' is not in the scope's allowlist/);
+    expect(err.details).toEqual({ operation: 'update', object: 'sys_user_permission_set', permissionSet: 'finance_admin' });
+  });
+
+  it('CONTROL: re-naming a grant between two allowlisted sets is admitted', async () => {
+    const r = renameHarness();
+    await expect(r.rename('g_sales', 'support_user')).resolves.toBeUndefined();
+  });
+
+  it('CONTROL: a tenant-level administrator re-names any of these grants freely', async () => {
+    const r = renameHarness();
+    for (const [id, to] of [['g_fin', 'sales_user'], ['g_west', 'sales_user'], ['g_retired', 'sales_user'], ['g_sales', 'finance_admin']] as const) {
+      await expect(r.rename(id, to, r.as('tenant_admin')), `${id} → ${to}`).resolves.toBeUndefined();
+    }
+  });
+});