Loomworks — Engine-enforced authentication standing note

Version. 0.1 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. 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).

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.

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, 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; 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, verified engine-side. A delegated service principal that lets a wrapper commit without the user's proof would re-introduce the very bypass this principle forbids.
• The API contract must expose weighty actions only behind the verifiable-proof 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, not auth-stubbing it.
• "The Companion is now a client" can be checked against this: the refactored brain must obtain and present the user's weighty-action credential 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. 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).