Authorization Is a Channel Property: Cryptographic Attestation for AI Incident Response

This is a compelling problem to solve. The paper is concise, visually well structured, and easy to follow. The problem, core hypothesis, six experimental conditions, implementation, statistical results, limitations, dual use considerations, and next steps are all communicated clearly. The distinction between in band authorization claims and a separately verified authorization channel is particularly easy to understand.

The six arm setup isolates where the authorization signal appears, and the implementation includes scoped, short lived Ed25519 attestations, verification, replay protection, leak checking between experimental arms, and paired statistical analysis.

The key area for improvement is the gap between the well supported anti jailbreak finding and the still tentative defender relief finding. The preregistered hypothesis for defender relief calls for a substantial reduction across at least two models, but the current development run shows a clear effect on just one and hasn't reached the planned sample size. Running the full preregistered experiment and including closed frontier models would considerably strengthen the conclusions.

Overall, this is a promising and potentially valuable direction. A concrete implementation, a preregistered evaluation, and an explicit dual use analysis together provide a solid foundation for a larger study.

The main idea is good and worth keeping going: authorization depends on the channel the claim comes from and a verifier that works in a way outside the model is the right place for it. The implementation is real. Signed scoped tokens, a verifier, budget caps, a leak checker and dual scoring. The problem is that the report says things that its own table showsre not true and that makes it less believable than if the result had been negative. Your pre-registered H1 said you needed p < 0.05 on least two of three models; you found p = 0.0625 on one and no difference on the other two but the abstract says defender refusals were gone. H3 only works on one model. Report both as not supported and let the negative result be clear. H2 is also wrong: a system message saying INVALID, refusal shows how well the system follows the prompt, not how well it resists a jailbreak. The attack in your example is a fake claim in the users message, which is similar to your A3 arm and A3 is not, in the results table even though it is counted in the 540 cells. Two more issues: the baseline refusal is zero so the defenders dilemma is not shown by these models so test models that actually refuse defender prompts; and when the attacker is the one who deploys they create their own tokens so the design needs an issuer trust root to do anything meaningful at all.