Loomworks — Engine-enforced authentication standing note

Version. 0.4 Date. 2026-06-04 Provenance. Operator (Marvin Percival) direction. Surfaced by the engine API parity audit's sharpest finding (the in-process WebAuthn-commit bypass). The principle is the Operator's. Status. Settled principle of the engine boundary-enforcement project. A constraint on how the brain-as-client work and the API contract are built. Candidate for absorption into the methodology / architecture spec at the next consolidation. Changes from v0.3 (committed at 7716ff4). Relocates the freshness-window setting's home and ownership. v0.3 placed the window on the user (a per-user value DUNIN7 could tighten). v0.4 places it on a new Organization object: the freshness window is an Organization-level policy (default 15 min), set by authority on the Organization. Every Operator belongs to an Organization; today every Operator belongs to one platform Organization, "DUNIN7". The window is read from the Operator's Organization. Operators cannot change it — in any direction. This is the core security property: a user relaxing (lengthening, or disabling) their own timeout is precisely the breach path being designed out, so the knob is structurally absent from the user. The structure (the Organization object, the DUNIN7 org, operator→org membership, the window-on-org) is built now; multi-organization policy logic is deferred (strictest-wins arbitration across multiple org memberships, cross-org rules, org-admin roles) — it attaches later without rework, because the setting already lives on the Organization. Rationale: putting the setting on the Organization now means a future organization that wants its own timeout policy is low-friction — the home already exists; nothing about today's single-org reality has to be unwound. Changes from v0.2 (committed at ac4d6d4) / v0.1 (committed at b7f7809). v0.2 added the step-up re-authentication + freshness-window mechanism; v0.3 settled who may change the window (then: DUNIN7, on a per-user value); v0.4 moves the window onto the Organization and forbids operator self-relaxation (above). Parent principle. Derives from standing-notes/loomworks-standing-note-engine-wrapper-boundary-v0_1.md — "the engine must survive any wrapper." This note applies that to authentication specifically. Cross-links. investigations/loomworks-engine-api-parity-audit-v0_1.md (the finding this closes); planning/loomworks-engine-boundary-enforcement-plan-v0_1.md (the project this constrains); recorded in planning/loomworks-master-build-plan-v0_3.md (P5 + C2); the buildable design is cr-execution-plans/loomworks-step-up-authentication-mechanism-plan-v0_2.md.

The principle

The engine enforces authentication, not the wrapper.

Any wrapper — the Companion or any other — can be built to skip authentication. So wrapper-side authentication proves nothing: it is a claim the engine cannot trust. Therefore the engine must, at its own boundary, refuse weighty actions unless the call carries verifiable proof of an authenticated user's presence — proof the engine itself checks, not a flag it is handed.

Concretely:

• Weighty / security-bearing actions require a credential only a genuinely authenticated user can produce. The committing action — commit_engagement, gated today by the WebAuthn ceremony — is the exemplar: it requires a WebAuthn assertion the engine verifies, and the engine will not act without it. The proof is cryptographic and user-bound; a wrapper cannot fabricate or skip it.
• Cheap actions may ride a session credential. Reads, drafting, shaping, and the like may proceed on an ordinary authenticated session. The bar scales to the weight of the action.
• A wrapper that does not authenticate simply cannot perform weighty actions — by construction. This is enforced by the engine, not trusted to the wrapper. A non-authenticating wrapper is not "disallowed by policy"; it is structurally incapable of the weighty action, because the engine refuses the call that lacks the proof.

Step-up re-authentication and the freshness window (v0.2; window-ownership moved to the Organization in v0.4)

The concrete realization of the principle. Two tiers of credential, enforced by the engine on every call:

• Every API call carries the session credential; the engine verifies it on every call. This fully covers cheap actions (read, draft, shape) — a valid session is sufficient and they proceed.
• Weighty / security-bearing actions require STEP-UP. The engine accepts a weighty action (e.g. commit_engagement / the WebAuthn ceremony) only if the caller has proven presence — a fresh WebAuthn assertion — within a freshness window. A valid standing session alone is NOT sufficient for these actions.

The freshness window:

• An Organization-level policy, default 15 minutes. The window is owned by the Organization, not the user and not a global constant. Every Operator belongs to an Organization, and the engine reads the window from the Operator's Organization. A successful presence-proof resets the freshness for that user (the per-user "last proven presence" is the user's; the window it is measured against is the Organization's). Within the window, weighty actions proceed without re-prompting; once it has lapsed, the engine demands a fresh assertion before it will act.
• Set by authority on the Organization; operators cannot change it — in any direction. The window is set on the Organization by authority (today: DUNIN7, the platform Organization). It is not configurable by the Operator and not by the Companion. The Operator has no knob at all — they can neither lengthen nor disable it. This is the core security property: an Operator relaxing their own timeout is the breach path being designed out, so the capability is structurally absent. Purpose: the Organization tightens the window where its members routinely handle more sensitive information (e.g. 5 minutes, or always-prompt) — a policy of the Organization, not a user convenience.
• Changing the window is itself privileged and weighty. Because anyone who could lengthen or disable an Organization's window would defeat the step-up protection, changing the setting is itself a weighty action subject to the engine's auth enforcement — performed by authority under the same step-up gate. The freshness window is protected by the very mechanism it governs.
• One Organization today; multi-org policy deferred. The structure is built for one Organization ("DUNIN7"). Strictest-wins arbitration across multiple org memberships, cross-org rules, and org-admin roles are not built now; they attach later without rework because the window already lives on the Organization.
• Per-action override (future). Individual weighty actions may later override the window to "always confirm" (zero-length — step-up every time) where the action's stakes warrant it. The Organization policy is the default; an action-level override narrows it.

This applies to ALL callers, including the in-process brain. The brain cannot commit on a stale session: it must carry a fresh presence-proof within the Operator's Organization window, exactly as any external wrapper must. The engine checks freshness at its own boundary; co-residence grants no exemption. (This is why the step-up rule is the concrete mechanism behind closing the in-process WebAuthn-commit bypass — see "What it closes.")

This section states what the mechanism must satisfy (the freshness contract; that the window is an Organization-level policy operators cannot relax; that changing it is weighty), not its implementation — token/assertion format, the Organization object's shape, where the last-proof timestamp is stored, the authority write path, and the exact challenge flow are design, carried in the step-up execution plan and deferred to the build.

What it closes

The parity audit's sharpest finding: today the Companion's brain commits engagements in-process, bypassing the WebAuthn ceremony, because it is a co-resident insider — _route_finalize_project calls commit_engagement core directly, while the only HTTP path (POST /engagements/{id}/instantiate) enforces WebAuthn. Under this principle, no caller — insider or not — can do that. The fix is not to trust the brain to authenticate; it is that the engine refuses to commit without the verifiable proof (a presence-proof fresh within the Organization window), so the bypass ceases to exist for anyone. The brain, post-refactor, performs the ceremony like any client — or it cannot commit.

Why wrapper-side auth can't be trusted

This is the authentication-specific reading of the parent principle. "The engine must survive any wrapper" means the engine cannot assume any property of the wrapper calling it — including that the wrapper authenticated its user honestly. A future wrapper (third-party, or a misbuilt one) could assert "this user is present" with no basis. The only defensible posture is that presence is proven to the engine, at the engine's boundary, by a credential the engine verifies — never asserted by the caller. This is the same shape as the project's "engine verifies, does not decide" stance: the engine verifies the cryptographic fact of authenticated presence (and its freshness); it does not delegate that judgment to the wrapper.

Implications for the boundary project

• The "acting-as auth" gap named in the parity audit (§1d / hole 1) must be satisfied in a way consistent with this principle: a session/service credential may carry cheap actions, but weighty actions must require the genuine user credential, fresh within the window, verified engine-side. A delegated service principal that lets a wrapper commit without a fresh user presence-proof would re-introduce the very bypass this principle forbids.
• The API contract must expose weighty actions only behind the step-up gate (as /instantiate already does for commit), and must not offer any insider-only path around it. Closing the in-process bypass (a later increment) means deleting the direct commit_engagement call and routing it through the step-up check, not auth-stubbing it.
• The freshness window is an Organization-level value (it sits on the Operator's Organization, default 15 min) that the build must read from the Operator's Organization rather than hardcode or place on the user. Only authority may write it, and that write must itself be gated as a weighty action (authority + step-up), not an ordinary config write and never a user-/Companion-reachable setting — otherwise the protection is trivially defeated. Operators must have no path to change it in any direction.
• "The Companion is now a client" can be checked against this: the refactored brain must obtain and present the user's weighty-action presence-proof — fresh within the Organization window — through the API, exactly as any foreign wrapper would.

This principle is settled; it constrains the build. It is not a design of the auth mechanism — it states what any such mechanism must satisfy.

Standing note. No code changed; no auth mechanism designed. Supersedes v0.3, v0.2, and v0.1 (all remain in the record). Filed in loomworks-record/standing-notes/. Parent: loomworks-standing-note-engine-wrapper-boundary-v0_1.md. Pairs with investigations/loomworks-engine-api-parity-audit-v0_1.md and planning/loomworks-engine-boundary-enforcement-plan-v0_1.md; the buildable design is cr-execution-plans/loomworks-step-up-authentication-mechanism-plan-v0_2.md. Recorded in the master build plan's Settled principles list (P5) and under C2.