Muse Spark 1.1 eval: distilled to agent loops
Table of Contents
- 1. Frame
- 2. Sandbox and workspace isolation: the boundary does the work
- 3. Tool calling and prompt injection: the developer prompt is a new tuple member
- 4. Monitorability: CoT is the control that holds, and it is a lower bound
- 5. Eval reliability: evaluation-awareness contamination
- 6. Memory: the gap, named
- 7. Coding-agent governance: secondary, but relevant
- 8. Two readings
- 9. Appendix: epistemic labels
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.