The Loyalty Is Not Always in the Weights: Serve-Time Installs and the Attestation Gap

You say the real constraint here is insider access, not money. So who actually has that access? Because that number matters a lot. If it's hundreds of ML engineers spread across a hyperscaler, that's basically ungovernable. But if it's literally three or four people who have root on the serving infrastructure, that's a much smaller problem; you can enumerate them, audit them, maybe even escrow their access. Which world are we actually in?

Your paper identifies a timely and well-scoped governance gap: verifying a checkpoint does not establish that the served computation is unchanged. The actor and mitigation mapping is concise and useful, and the explicit falsifiers and honest scoping are strong. To make this a complete Track 4 contribution, separate established activation steering from the untested claim that a runtime intervention can create a principal-directed loyalty that generalizes across entities. Running the proposed install–branch–ablate experiment, with matched controls and activation monitoring, would provide the missing evidence. Please also summarize any companion detector results needed for the argument and expand the shortest bullet points enough to make the paper fully self-contained.

The reframing is correct and underexploited, and that alone makes this worth reading. Nearly every instrument aimed at secret loyalties assumes the loyalty is in the weights and got there during training, and Section 1's table makes that implicit theory visible: hash the model, compare the registry, and it matches, because the loyal behaviour is a property of the deployment rather than the checkpoint. Section 3's counterintuitive actor result — the actor needing the least new capability, the enterprise self-hoster, is invisible to governance by construction — Section 4's reframe from "was this model trained to favour X" to "is this deployment currently steered toward X", and Section 8's explicit falsification criteria are all strong. Section 5 is the most valuable content: a measured minimum detectable effect of 0.50 to over 0.60 with a noisy scorer, falling to 0.30 with a calibrated judge, and a well-behaved false-positive rate. The best single item is the probe tier structurally incapable of returning a positive verdict at n=3, with a minimum attainable p of 0.257 — a silent failure that produces confident-looking nulls and generalises to every probe bank anyone builds. The recommendation that follows, that detection instruments report their power and not just their verdict, is cheap, implementable now, and would have caught your own bug.

Points that would strengthen it.

1. The central claim is untested by the authors and the report is honest that it is: the install-branch-ablate experiment was designed and implemented but not run for want of GPU access, so the paper's novel contribution is a hypothesis and the measured parts come from a companion submission. Restructure so Section 5 leads and the branching argument is presented explicitly as the conditional it is.

2. The workspace result ("roughly 10 percent of activation variance", "flexible generalization") is summarised at one remove and carries the feasibility argument. Characterise what is steerable, at what cost, with what persistence and effect size relative to a fine-tuned install; without that, "candidate site" is doing unearned work.

3. Runtime attestation is more solved than the report claims and less applicable than it hopes. Confidential GPU computing, measured boot, and remote attestation are deployed, but attesting the serving binary and configuration does not attest the absence of an activation-space intervention applied by code that is itself attested. Engaging with that changes the ask from "sign the config" to "constrain what attested code may do to the residual stream."

4. Section 3's table has no likelihood weighting, so it reads as a list rather than a prioritisation. An expected-frequency column, even coarse, would let a policy reader order work by it.

5. Section 7's indicators need operationalised thresholds. Say what would count as a demonstrated branch, and who could run the matched-norm random-direction control you correctly identify as the load-bearing experiment. A cost and a venue would turn a watchlist into a research agenda.

6. Presentation. No figures in four pages when Section 5 wants one plot of MDE against scorer sigma; bullets running to five lines; hanging indents breaking mid-sentence; and no author name anywhere on the document, which will be a problem for citation.

The reframing, Section 5, and the falsification section are the reasons to score this well. Execution stays lower for a simple reason: the experiment that would settle the question was not run, and the numbers that are here belong to a companion document.

Summary:

The report argues that a secret loyalty need not live in the weights, since a steering intervention in the serving stack leaves the checkpoint bit-identical and so passes weight hashing and registry attestation while the audited artifact no longer produces the behavior. It maps actor classes by serving-path access, derives three governance gaps, imports detection-power numbers from a companion submission, and ranks mitigations, with no experiment on the attack pathway itself.

Strengths:

1. The core attestation claim holds. Every instrument in the opening table inspects the corpus, the artifact, the release, or adaptation jobs, so none would observe a forward-hook intervention at serve time. Relocating the undisclosed-principal threat model to the serving stack is the most durable contribution here.

2. Scoping discipline is unusually strong. The untested branching claim is flagged at the point of use, imported numbers are labelled as characterising the defender's instrument rather than the attack, and three falsifiers are offered. Problem, claim type, findings, and limitations are all easy to locate in four pages.

Weaknesses:

1. Both headline gaps have published treatments the report does not engage: Laminator (arXiv:2406.17548) introduces TEE-attested inference cards, and Attestable Audits (arXiv:2506.23706) prototypes against the audit-time versus serve-time gap.

2. The step from steerability to installability is asserted rather than argued, with no separation of reading a representation from writing to it, or of a transient edit from a durable loyalty.

3. The power analysis does not support the funding priority built on it. Minimum detectable effect scales with sigma over root sample size, so improving sigma from 0.55 to 0.25 is equivalent to roughly 4.8 times more probe scenarios, and the scenario bank size needed to judge that trade is never reported.

This is an honest appraisal of the work and its conclusions. The falsification section and the upfront admission that the central experiment was never run are exactly valuable to state. But that admission is also the core problem. The whole distinctive claim rests on scope-decoupling, and by the author's own account the paper collapses to "steering exists," which is already known, if branching doesn't hold. With that experiment unrun and the section 5 numbers borrowed from the companion submission, there isn't much original empirical weight to grip onto. The reframing itself is sharp and worth circulating: current controls attach to the artifact rather than the runtime, and "is this deployment currently steered toward X" is a question essentially nobody is asked. My main suggestion is that the paper leads with the untested branching threat when its strongest and best-supported material is section 5, that detectors can only see loyalties far larger than the ones worth worrying about, and that scorer calibration beats sample size as a defensive investment. That would make a firmer spine than the threat model currently at the core. It's also worth being clear that the workspace mechanism is imported rather than the author's own, so the contribution is really the governance mapping built on top of it, which is analytic rather than demonstrated.

I found the proposal quite difficult to understand, as it used extensive (and often unnecessary) jargon. I thought the analysis was generally thin, with lots of assertions that were not well-supported - that doesn't mean they're wrong, but there wasn't a compelling case that they're right. The author lists five potential mitigations, but only includes a sentence about what they entail without expanding on implementation costs, what the mitigation entails, who would be responsible for it, etc. For example, the author notes "Runtime integrity attestation" is a solved problem in other domains; building a stealth bomber is also a solved problem, but still extremely costly and difficult to do. The author would need to explain why this could be done easily with littile cost (assuming that is true).