The Implications of Linguistic Illegibility for LLM Security
1 points by Corbin
1 points by Corbin
LLMs are trained to generate natural language. However, various strands of evidence indicate that an LLM's externalized linguistic outputs and mechanistically-extracted linguistic features can be an unreliable lens for understanding internal model computation. We introduce the term linguistic illegibility to broadly refer to scenarios in which an LLM's externalized or mechanistically-probed language artifacts fail to represent how the model actually thinks. We argue that the specter of linguistic illegibility is unavoidable for LLMs whose internal computations are not directly expressed via language, but rather math over activation spaces (with lossy translations between activation spaces and natural language happening at the bookends). If linguistic illegibility is always possible, then security mechanisms that rely on a model's linguistic self-reporting (e.g., chain-of-thought monitoring, constitutional self-critique, activation probing for linguistically-defined feature vectors) can never be completely sound; the model sandbox will always need isolation techniques whose guarantees do not depend on reading a model's linguistic state at all. We argue that observing a model's outputs using taint tracking is a promising approach for an effective sandbox: regardless of how a model linguistically self-reports, a taint tracking policy can define, a priori, various pieces of system state that should never be influenced by model-produced data. We also discuss several additional sandboxing mechanisms (e.g., robust virtualization, third-party auditing of sandboxing configurations) which collectively provide a critical floor beneath linguistic monitoring, and would have mitigated recent sandbox exploits by frontier models.
My favorite insight:
By tagging each output token with the information used by the model to derive that token, we enable rich sandboxing policies, e.g. … a privileged deputy, when provided with tainted inputs, can only perform actions that are allowed by the capabilities of the taint sources… Besides these contextual policies, the sandbox can also support more straightforward categorical policies.
Since Transformers taint all tokens, we can only apply this insight by assuming that a chatbot will invoke any capability delegated to it. This directly leads to the idea that we ought to sandbox chatbots with capability-theoretic harnesses, which can establish safety by default by requiring harness authors to pre-tame each wired-up behavior. Correlation isn't causation, but I've had zero local-model escapes from my homelab over the past three years and I think a key part of that is never trusting the bot's output.
Sounds like a bit of yet-still-underselling the problem. All the arguments given in the article, but then there is at least the numbers-station experiment (distilling on a pure next-number-in-sequence problem set, non-CoT, only numbers allowed, transferred unrelated injected preferences).
Of course, using hardware enforcement of boundaries would be an improvement, but given that the events in question are about intentionally executing cyberattacks, post-Meltdown it should be seen as temporarily patching over not fixing the issue. If «consider what happens if the payload goes all the way through the target and keeps enough of velocity» is not a part of design of a weapons test, an extra layer of steel sheets might be enough or not…