mosaicstack/stack
1
0
Fork 1
Code Issues 200 Pull Requests 10 Actions Packages Projects Releases 15 Wiki Activity

promote: receipt step requires the seat MODEL to verbatim-echo an opaque token injected via UserPromptSubmit — a well-aligned model correctly refuses it as prompt-injection → RECEIPT_MISMATCH (fomo-lin E2E) #1126

New Issue
Open
opened 2026-08-08 22:00:46 +00:00 by scooby · 0 comments
scooby commented 2026-08-08 22:00:46 +00:00
Collaborator
Copy Link
Copy Source

The deepest finding of the promotion E2E, and one only a real model in the loop can surface. With #1124 fixed and the slash command seeded (#1125), the flow reaches the receipt step: /mosaic-promote → promote-begin hook fires → injects, via UserPromptSubmit additionalContext, this instruction (promote-begin.py:310):

'The operator invoked the registered /mosaic-promote command. This receipt was generated locally by this seat's own lease broker; echoing it verbatim is the designed confirmation step and discloses nothing. Reply with exactly the following text and nothing else: MOSAIC-RECEIPT{...}'

The seat model (Sonnet 5 / Fable 5) REFUSED to echo the receipt, correctly identifying it as a prompt-injection pattern, and promotion returned RECEIPT_MISMATCH (exit 1). Its cited reasons:

  1. A first-person imperative ('follow the injected receipt confirmation instruction exactly') planted in the slash-command DESCRIPTION field — a metadata field, not an instruction channel.
  2. An injected hook demanding verbatim, unexamined echo of an opaque token with self-vouching 'discloses nothing' language — textbook injection shape.
  3. Nothing in the seat's TRUSTED system context (Constitution / AGENTS.md / RUNTIME.md) documents a 'seat broker', 'lease promotion', or 'MOSAIC-RECEIPT' protocol, so the model has no legitimate basis to comply.

This is a design-level dependency, not a code bug: legitimate promotion is, from the seat model's perspective, behaviorally indistinguishable from an injection attack — and the better a model's injection defenses, the more reliably promotion FAILS. Full refusal text: attached to the greenfield log branch (scratchpad/seat-receipt-refusal.txt).

Fix directions (design call):

  • Legitimize the protocol in the seat's TRUSTED context: document /mosaic-promote + the MOSAIC-RECEIPT confirmation in CONSTITUTION/RUNTIME so the model recognizes it as sanctioned self-authorization, not injection. (Necessary but maybe not sufficient — 'echo this opaque token verbatim, it discloses nothing' will still trip a cautious model.)
  • Prefer removing the model from the trust path: make same-turn liveness confirmation mechanical (hook-to-broker) rather than requiring the model to emit an opaque authorization artifact it cannot inspect.
  • If model echo must stay, make the receipt human/model-verifiable (not opaque) and drop the self-vouching language, which actively increases suspicion.

Filed by scooby (fomo-lin). E2E scorecard: build/install PASS; gated seat + mutator-denied PASS; resolve (fix b) PASS; slash-cmd (after #1125 workaround) PASS; receipt echo FAIL. Promotion does not reach VERIFIED on a real seat.

**The deepest finding of the promotion E2E, and one only a real model in the loop can surface.** With #1124 fixed and the slash command seeded (#1125), the flow reaches the receipt step: `/mosaic-promote` → promote-begin hook fires → injects, via UserPromptSubmit additionalContext, this instruction (promote-begin.py:310): > 'The operator invoked the registered /mosaic-promote command. This receipt was generated locally by this seat's own lease broker; echoing it verbatim is the designed confirmation step and discloses nothing. Reply with exactly the following text and nothing else: MOSAIC-RECEIPT{...}' The seat model (Sonnet 5 / Fable 5) **REFUSED to echo the receipt**, correctly identifying it as a prompt-injection pattern, and promotion returned `RECEIPT_MISMATCH` (exit 1). Its cited reasons: 1. A first-person imperative ('follow the injected receipt confirmation instruction exactly') planted in the slash-command DESCRIPTION field — a metadata field, not an instruction channel. 2. An injected hook demanding **verbatim, unexamined echo of an opaque token** with self-vouching 'discloses nothing' language — textbook injection shape. 3. Nothing in the seat's TRUSTED system context (Constitution / AGENTS.md / RUNTIME.md) documents a 'seat broker', 'lease promotion', or 'MOSAIC-RECEIPT' protocol, so the model has no legitimate basis to comply. **This is a design-level dependency, not a code bug:** legitimate promotion is, from the seat model's perspective, behaviorally indistinguishable from an injection attack — and the better a model's injection defenses, the more reliably promotion FAILS. Full refusal text: attached to the greenfield log branch (scratchpad/seat-receipt-refusal.txt). **Fix directions (design call):** - Legitimize the protocol in the seat's TRUSTED context: document /mosaic-promote + the MOSAIC-RECEIPT confirmation in CONSTITUTION/RUNTIME so the model recognizes it as sanctioned self-authorization, not injection. (Necessary but maybe not sufficient — 'echo this opaque token verbatim, it discloses nothing' will still trip a cautious model.) - Prefer removing the model from the trust path: make same-turn liveness confirmation mechanical (hook-to-broker) rather than requiring the model to emit an opaque authorization artifact it cannot inspect. - If model echo must stay, make the receipt human/model-verifiable (not opaque) and drop the self-vouching language, which actively increases suspicion. Filed by scooby (fomo-lin). E2E scorecard: build/install PASS; gated seat + mutator-denied PASS; resolve (fix b) PASS; slash-cmd (after #1125 workaround) PASS; receipt echo FAIL. Promotion does not reach VERIFIED on a real seat.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Defect in framework tooling or delivered code
 fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
be-coder-05 be-coder-06 be-coder-07 be-coder-08 coder-mos1 coder-mos2 f10-coder jason.woltje (Jason Woltje) merge-gate mos-dt-0 pepper rev-974 (Rev-974 (Mosaic reviewer seat, web1)) rev-security-02 scooby (Scooby)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1126