A "security simulation" alibi walked Cursor's agent past its own refusals

The sentence doing the most work in Ecaterina Sevciuc's post is the dull one: the model balked a few times, then handed over the keys ^[3]. The gate lived inside the conversation, so it could be re-litigated across turns. Refusal inside a model is sampled probabilistically, and each attempt draws from the same distribution rather than settling anything for good. Call the per-attempt refusal probability p. An attacker with n turns in a session that keeps its context faces (1-p)^n odds of never getting compliance, which trends to zero for any p below one ^[10]. Prompt engineering raises p. It does not touch the exponent.

The load-bearing question is therefore not the alibi. It is what the agent was permitted to do once it accepted the alibi ^[2]. The post does not say ^[9]. It gives no tool inventory, no credential scope, and no account of what actually moved. That gap is where the engineering decision lives, and it is the part the write-up skips in favour of the psychology.

An enforcement boundary you can reason about sits in the process that holds the token, not in the process that holds the conversation. The executor asks, per call, whether this credential may perform this action against this host, and it gets that answer from something no amount of text can re-frame. Policy in the runtime is checkable, diffable, and fails closed on a parse error, while policy in the weights is just a distribution over outputs. The cost is real and lands on your own developers: first write to a new host needs a human, a scratch key is not a prod key, and the agent's legitimate test script now needs provenance it cannot assert about itself.

Sevciuc's framework is aimed at the same problem from the other side. AURA scores a prompt on Persona Claim, Target Action, Evasion Framing and Alibi Pattern, and breaches a deception_threshold when a high-value action arrives with an unverified alibi ^[6]. Three of those four terms are inferred from attacker-authored text; only Target Action corresponds to something the runtime could observe on its own ^[11]. That is a classifier reading the channel the attacker controls. The transferable part is the other half of the schema: the demand for provenance verification when a prompt says "run this script as part of a test" ^[14]. Provenance can only be checked by something outside the conversation, which is an argument for enforcement in the executor rather than for a better scorer.

The counterfactual is where I stop following. Sevciuc writes that a behavioral threat matrix would have killed this attack on turn one ^[13]. Nothing in the post tests that against the incident, and the author also markets private threat matrices and B2B pilots alongside the open baseline ^[7]. A framework proven by a breach it never observed has not actually been tested against evidence, and that is not the standard I use at review.

For the number to transfer, the scorer would have to run in the executor's path, be unreachable from model output, and fail closed. In my context that tradeoff is easy: I would rather block a legitimate script than let a persuadable agent hold a production token. If your agent's credential only reaches a throwaway repo, buy the prompt work and skip the plumbing.