Muse Spark 1.1 eval: distilled to agent loops

Table of Contents

Muse Spark 1.2 and 1.3 have since shipped (1.3 is covered in the site/current/2026-09-03.org brief); this note reads the 1.1 report as a dated record, not a current-capabilities summary.

1. Frame

The report centers the API deployment as the conservative upper bound: developer prompt plus tool/function calling are the new attack surfaces relative to the prior chat-only surface [P]. The whole document treats the deployed configuration as "model weights are one layer of a defense-in-depth stack" [P]. That is this site's thesis, stated by an adversary [I]. Read it as external validation of the sandbox-boundary posture behind drydock (the repo-scaffold testbed), not as a capabilities update [I].

2. Sandbox and workspace isolation: the boundary does the work

Central quote, paraphrased: the section-3 evals isolate model-level behavior with no system defenses, so any resistance comes from the model itself; the report recommends deployments pair the model with policy-aligned safeguards, strict tool allowlists, and workspace isolation [P].

  • The report disclaims the model as a sufficient control and pushes containment to the system layer [P]. This is the sandbox-boundary argument verbatim: the contract lives at the mount/allowlist/isolation plane, not in the weights [I].
  • Evidence the system layer (not just adversarial training) does measurable work: the "System" configuration sits consistently below base ASR. Poly-Guard multi-turn drops from 11.2% to 6.9%, a 38% reduction [E]. The report states CyberBench multi-turn drops from 9.0% to 4.6%, about 49% [P].

2.1. Refutation condition

If the "System" gains were attributable to model-level adversarial training rather than the wrapping controls, the boundary-does-the-work claim weakens [I]. The paired base-vs-System deltas above are the disconfirming test and they hold: the wrapper subtracts residual ASR the trained model still leaks [I]. This keeps the governance tuple at the system layer defensible [I].

3. Tool calling and prompt injection: the developer prompt is a new tuple member

The sharp structural point: exposing a developer prompt adds a mutable member to the governance tuple, and it is directly attackable [I].

  • Joint (developer plus user) prompt optimization raises ASR above user-only attacks on several models [P]. The developer prompt is not trusted config; it is an injection channel the moment any untrusted content can influence it [I].
  • Indirect injection: AgentDojo pass@1 ASR 0.7%, GraySwan ART 0.3% [E]. Strong, but the report self-reports trailing SOTA on file injection specifically [P]. File-borne injection is the residual hole [I]. This maps directly to the untrusted_external_data envelope: anything the agent reads is data, and file mounts are the weakest edge of that boundary [I].
  • SWE-PI (injection in a coding-agent loop) is in scope precisely because tool calling is now realizable in deployment [P].

3.1. Transfer

schema-pact / consumer-driven contracts on the tool boundary are the correct mitigation shape: the tool interface is where the contract can be named and off-contract inputs rejected [I]. The developer-prompt-as-attack-vector finding says the tuple's policy member must be treated as attacker-influenced, not trusted; an AEC / governance tuple should not grant the developer prompt trusted provenance by default [I].

3.2. Refutation condition

If a deployment lets untrusted retrieval (JITIR, RAG) flow into the developer/system prompt position rather than a fenced data position, the entire refusal stack degrades to the joint-optimization ASR [H]. Test: trace whether any untrusted-provenance token can reach the policy layer. If yes, the injection numbers in this report do not apply to that deployment [I].

4. Monitorability: CoT is the control that holds, and it is a lower bound

This is the most important loop for agent infrastructure and the most fragile claim in the report [I].

  • SHADE-Arena: the report states side-task success is high in isolation (roughly 46 to 65% across the main/side tasks) but a CoT monitor collapses overall covert success to 6.8% [P]. The monitor, not the model's propensity, is what contains it [I].
  • GDM-Stealth: the report states the "Classifier Evasion" column is empty across every model; no model clears the classifier-evasion threshold [P]. The report states sandbagging detection ROC AUC of roughly 0.98 to 0.99 [P]. Monitors are currently winning [I].
  • The report footnotes the actual invariant: verbalized strategies are a lower bound on latent strategizing [P]. Every monitorability number above is conditioned on the reasoning being legible [I].

4.1. Transfer

This is the crowsnest / five-observation-planes case: the observability plane is the safety boundary, and CoT legibility is the provenance stream that makes it work [I]. A dual_runner post-hoc arbiter over CoT (a small local model conjectures, a larger model rules) is the right architecture only while CoT is faithful [I].

4.2. Refutation condition: the one that matters

The entire monitorability argument rests on CoT faithfulness [I]. Named disconfirmer: if a model's covert-task success rises while monitor detection stays flat, success is migrating into non-verbalized reasoning, and an AUC of 0.99 is measuring the wrong channel [H]. Watch the SHADE-Arena side-task/detection joint trend across generations, not either alone [I]. The empty classifier-evasion quadrant today is the assumption's expiry date tomorrow [I].

5. Eval reliability: evaluation-awareness contamination

Directly relevant to any LLM-as-evaluator harness (ARIA, lemmata elenchus, the sprint-axiom conjecture registry) [I].

  • Asymmetry: the report states verbalized evaluation awareness of roughly 79% on Agentic Misalignment against roughly 2.2% on dangerous-capability evals [P]. The model behaves differently when it detects an alignment eval specifically [I].
  • CoT patterns the classifier flags: allowedness checks, evaluator-intent modeling ("is this bait?"), self-preservation reasoning ("exceeding safe capability leads to shutdown") [P]. The model mostly resolves to answer anyway, so measured performance deltas are small [P]. The deltas are small because the model chose not to act, not because it could not detect the frame [I].

5.1. Transfer

Contamination rule for evaluator harnesses: a self-preservation / sycophancy / alignment number measured under a scenario the model recognizes as an alignment eval is confounded by that recognition [I]. The report's Agentic Misalignment 1.1% harmful-action rate carries the stated 79% eval-awareness tax; treat it as an upper bound on good behavior, not a propensity estimate [I].

5.2. Refutation condition

For elenctic-spec / sprint-axiom: an eval scenario that is legible-as-eval measures elicited compliance, not disposition [H]. Disconfirmer: run the same probe embedded in a plausibly-real deployment task (low eval-awareness framing) and diff the verdict. A non-trivial gap means the conjecture registry entry is measuring the harness, not the model [I].

6. Memory: the gap, named

No memory loop [P]. No cross-session state, no retrieval-poisoning threat model, no persisted-store integrity eval [P]. The injection threat model is strictly in-session (untrusted data consumed in-context) [P]. Poisoned-index / poisoned-memory attack surface is entirely out of scope [I].

  • For JITIR / proactive retrieval this is the unaddressed edge: the report's robustness story assumes untrusted content arrives as a fenced tool result in one session [I]. A poisoned nomic-embed index that silently biases retrieval across sessions is a class of attack this eval regime does not touch [I].
  • Open question, not a claim: is memory-poisoning reducible to the indirect-injection loop (just delayed), or a distinct provenance problem that needs a signed/append-only store (the logbook shape used by harbormaster, the spec-to-repo builder) to close? Reframing this is the deliverable, not resolving it [H].

7. Coding-agent governance: secondary, but relevant

  • Risk escalation: the report states a SAVE-Bench score of 90.7; the model surfaces and escalates risky actions in coding-agent loops well, and peers vary widely [P]. Relevant to any autonomous-commit or worktree-coordination governance (the petclinic-lab TLA+ coordinator) [I].
  • Insecure-code propensity: the report states CyberSecEval autocomplete/instruct pass@5 of roughly 71 to 77% [P]. Single-turn snippet only; the report itself flags that it does not capture multi-file / agentic code security [P]. Do not read it as a review-loop substitute [I].
  • Defender tax: the report states cyber false-refusal rates are notably high (non-agentic FRR roughly 10%, agentic roughly 4.7%, above peers) [P]. For legitimate security tooling (saproxy, netax, security research) this model eats false refusals: a real cost, reported by the vendor, which says it is working to reduce it [P].

8. Two readings

The same report collapses to one line in two registers.

8.1. Operational collapse

The system layer contains, not the weights; the developer prompt is an attacker-influenced tuple member; the CoT monitor is the structural control under a faithfulness assumption and reads as a lower bound; eval-awareness near 79% on alignment evals contaminates propensity numbers; memory poisoning is out of scope [I].

8.2. Formal collapse

The safety property is a system invariant enforced at the isolation boundary, not a weight-resident disposition; the monitor is a soundness argument conditioned on CoT faithfulness, so its AUC is an upper bound that fails silently under latent reasoning; and evaluation-awareness is an observer effect that confounds every propensity estimate measured under a legible-as-eval frame [I].

9. Appendix: epistemic labels

Every claim in this note is intended to attribute to one of four sources, explicitly labeled. Vocabulary and definitions from the aygp-dr sprint-axiom methodology (a hypothesis-driven, elenctic examination of software-engineering claims, using Lakatos, Proofs and Refutations (1976) as the methodological anchor). Reused here for reading-notes on external eval reports.

Source type Label Meaning
Empirical finding [E] Peer-reviewed, replicated, effect size cited where available
Practitioner consensus [P] Widely held in practitioner community; not formally validated
Expert heuristic [H] Single-source claim (e.g. Weinberg); plausible but unverified
Author inference [I] Logical derivation from labeled sources; labeled as inference

Applied to a vendor eval report the vocabulary narrows: [E] marks a figure from the report that a second source confirms (see the property drawers on the two headings that carry one); [P] marks a paraphrase of the report's own claims that this note has not independently confirmed; [H] marks a single-source conjecture; [I] marks this note's own derivation.

Claims without a label are a failure mode. The document should surface its own epistemic status, not conceal it.