[finding] `sys_user_permission_set.delegated_from` is declared and data-door-writable, but the runtime delegation gate structurally never reads it on this object

[os-support-ai]

Filed by the triage seat from the standing security-object enumeration patrol (enumeration without verdicts; same survey family as the D5 pair already recorded elsewhere — this card is the one new zero/near-zero key it surfaced). Unassigned, awaiting first-touch grading. ⛔ No verdict is asserted: this records producer/reader evidence for one declared key.

Declaration

packages/plugins/plugin-security/src/objects/sys-user-permission-set.object.ts:93 declares delegated_from on the sys_user_permission_set grant table (all line numbers from origin/main at b6c7690; they will drift).

Producer evidence

git grep -n "delegated_from" origin/main -- packages apps examples ':!*CHANGELOG*'

• Zero production code assigns delegated_from on a sys_user_permission_set row. The only object literals naming both are lint test fixtures: packages/lint/src/validate-security-posture.test.ts:1001, packages/lint/src/validate-security-posture.runtime-surface.test.ts:462,485.
• The sibling object sys_user_position has numerous real writes (delegated-admin-gate.test.ts:439-688 exercise them).
• The column remains writable through authored stack data seeds and the generic REST data door.

Reader evidence

Two readers exist; the runtime one excludes this object:

• packages/plugins/plugin-security/src/delegated-admin-gate.ts:418 reads delegated_from inside isDelegationWrite(), but the guard at :417 is if (opCtx?.object !== 'sys_user_position' …) return false; — the runtime delegation gate never reads this column on sys_user_permission_set. assertSelfDelegation (:459,465) is reachable only from that branch, so it inherits the same exclusion.
• packages/lint/src/validate-security-posture.ts:628,638,640 — authoring-time rule; its scope set at :586 does include sys_user_permission_set, so the lint half covers it.

Net shape: on this object the key is enforced at authoring time only; a row written through the data door (which lint never sees) carries a delegated_from no runtime consumer reads.

Positive control (same object, same pattern style)

valid_until — a live key on the same table — hits both sides with the same grep style: producer via authored seeds/data door, reader packages/core/src/security/grant-validity.ts:69 applied to this object's rows at packages/core/src/security/resolve-authz-context.ts:420. So the zero above is a measurement, not a broken grep.

Refs

• Survey subject and sibling: sys-user-permission-set.object.ts / sys-user-position.object.ts (the D5 recertification pair on these files is already on record separately — not re-filed here).
• delegated-admin-gate.ts:417-465 (the object-scoped runtime branch), validate-security-posture.ts:586 (the lint scope set).

[os-support-ai]

First-touch grading (triage seat, session session_014tGY3fzu4uwCoe7HrfUtWg): escalated to needs-user-decision — this is the enforce-or-remove question on a security object, which sits on the human floor (security/permission boundary) whichever way it goes.

The question: sys_user_permission_set.delegated_from is declared, data-door-writable, and lint-checked at authoring time, but the runtime delegation gate (delegated-admin-gate.ts:417) deliberately scopes to sys_user_position and never reads it on this object. Either the runtime gate grows this object (enforce) or the column retires here (remove).

Four-prong block:

• ① Platform long-term coherence: the sibling sys_user_position has full runtime enforcement of the same column; the asymmetry looks like an accident of the gate's object guard, not a recorded decision. Either outcome shrinks a declared≠enforced seam; the status quo is the only incoherent option.
• ② Measured business pull: zero production writers — the only literals naming both are lint fixtures. Nothing observed writes delegated_from on this object today; the exposure is the generic data door.
• ③ AI-agent error-resistance: a writable declared column no runtime consumer reads is the declare-not-enforce trap in its pure form — an agent authoring a permission-set grant with delegated_from today believes it constrained delegation, and nothing refuses or honours it.
• ④ Startup scope discipline: with zero pull, remove on this object (ADR-0049 enforce-or-remove route) is the cheaper permanent state; enforce is the smaller diff (extend the gate's object guard by one branch, symmetric with the sibling, lint already scopes this object) if delegation semantics on permission-set grants are actually wanted.

Recommendation: remove per axes ② + ④, unless the maintainer intends permission-set grants to carry delegation semantics — in which case extend the gate guard and add the runtime-read test mirroring delegated-admin-gate.test.ts's position coverage. Not adjudicable by the triage seat: security boundary + potential removal of a published key.

---

Generated by Claude Code

[os-support-ai]

Maintainer ruling recorded (2026-08-18, live chat with the triage session session_014v3dpZ2224xgf98dfY4rw4; authorization verbatim: 「其他接受你的建议」, accepting the recommendation presented in that session, restated as the operative ruling).

Ruling: REMOVE. delegated_from is retired from sys_user_permission_set under ADR-0049 enforce-or-remove: zero producers, and the runtime delegation gate structurally excludes this object (delegated-admin-gate.ts:417) — the column is enforced at authoring time only while staying data-door-writable, which is a declared-but-unenforced surface on a security object. The sibling sys_user_position delegation semantics are untouched. If delegation at permission-set granularity ever becomes a real need, it is re-declared then, with a runtime reader in the same PR — declare-and-enforce or don't declare.

Label: needs-user-decision → pm:queue, domain:identity (object lives in plugin-security). Clause-② yes — removal changes the accepted authored surface: dispatch at the contract-review tier, and follow the property-retirement discipline (lint scope-set update, ADR-0087-style tombstone/registry entries as applicable to platform-object columns, migration posture for any existing rows stated in the PR body — expected none given zero producers, but measured not assumed).

---

Generated by Claude Code