Loomworks — Engine-enforced authentication standing note

Version. 0.2 Date. 2026-06-03 Provenance. Operator (Marvin Percival) direction, 2026-06-03. 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.1 (committed at b7f7809). Adds the step-up re-authentication + freshness-window mechanism (new section below): weighty actions require a fresh WebAuthn presence-proof within a configurable window (default 15 min), a valid standing session alone is not sufficient, the window is a system setting (engine config) not hardcoded, changeable only by an authorized user — and changing it is itself a weighty action subject to step-up (who is "authorized to change it" is a flagged open sub-decision), individual weighty actions may later override to always-confirm, and this applies to all callers including the in-process brain. v0.1's content carried forward unchanged. 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_2.md (P5 + C2).

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)

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:

• Default = 15 minutes. A successful presence-proof resets the window. Within the window, weighty actions proceed without re-prompting; once the window has lapsed, the engine demands a fresh assertion before it will act.
• The window is a SYSTEM SETTING, not hardcoded. It lives in engine configuration so it can be tightened (e.g. to 5 minutes, or to always-prompt for a specific action) or adjusted operator-wide without a code change.
• Changing the window is itself privileged and weighty. The setting is changeable only by an authorized user, and changing it is itself a weighty action subject to the engine's auth enforcement (step-up). This is load-bearing: an unauthorized party who could freely lower the window — or disable it — would defeat the step-up protection entirely. So the freshness window is protected by the very mechanism it governs.
• Open sub-decision (flagged): which designation/role is "authorized to change" the freshness window is not yet defined. It must be settled before this is built (a candidate: an operator-level or system-administrator designation, but undecided here).
• Per-action override (future). Individual weighty actions may later override the global window to "always confirm" (zero-length window — step-up required every time) where the action's stakes warrant it. The global setting 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 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 and where the setting lives), not its implementation — token/assertion format, where the last-proof timestamp is recorded, and the exact challenge flow are design, 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 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 being a system setting means the engine config surface must carry it (with a 15-minute default), and the build must read it rather than hardcode — so it is adjustable operator-wide and per-action-overridable later. Writing that setting must itself be gated as a weighty action (authorized user + step-up), not an ordinary config write — otherwise the protection is trivially defeated. The "authorized to change it" role is the flagged open sub-decision above.
• "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 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.1 (which remains 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. Recorded in the master build plan's Settled principles list (P5) and under C2.