Before reasoning: a security abstraction for how LLMs construct reality

Most LLM security work focuses on what a model decides to do: whether it follows an instruction, violates a policy, calls a tool, or produces an unsafe action. There is an earlier problem, and it is easier to overlook because it produces no artifact of its own. Before a model can reason about an object, an instruction, a source, or a constraint, it has to construct a representation of what those things are. I have written about that step as the perception layer, and about the experiments that expose it.

This essay is about something narrower and more methodological: what kind of claim it is to say that such a layer exists, and why that claim is legitimate for a system whose internals we do not fully understand. It continues the fourth step of the method this publication is built on, building the smallest conceptual model that accounts for what was observed.

Why abstractions are the right kind of claim

We do not need a complete microscopic explanation of a system before we can reason about its security.

Complex systems are routinely understood through abstractions that the implementation does not literally contain. An operating system gives us processes, files, users and permissions. A network gives us layers, connections, routes and trust boundaries. Nobody believes the silicon holds a "process" as a physical object. The abstraction earns its place by giving us boundaries at which to reason, diagnose and defend, and by making predictions that can be checked: a permission that should have prevented an access, a layer that should not have been crossed.

Language models need the same treatment, and for the same reason. Their internal computation is distributed and not well understood, and the honest description of a forward pass is a single transformation from a sequence of tokens to a distribution over the next one. That description is true and nearly useless for security. It collapses several different ways of going wrong into one opaque category, and it leaves us with sentences like "the model got confused", which name the outcome and explain nothing.

So the layers I am about to describe are functional, not architectural. I am not claiming that a transformer contains a reconstruction module followed by a reasoning module. I am claiming that treating it as if it did lets us ask questions that can be answered by experiment, and that failures sort into those questions rather than smearing across them. That second claim is empirical, and I come back to how it could fail. Here, "before" names a logical dependency, not a demonstrated temporal separation in the model's computation.

The abstraction

canonical representation        P
        |
boundary / role / provenance / constraint reconstruction
        |
reconstructed representation    R
        |
reasoning
        |
action

P is what the application presents to the model, and it is the thing the application considers authoritative. The spreadsheet knows it rendered five rows. The mail client knows where one message ends and the next begins. The tool interface knows which value belongs to which field. All of that is P.

R is what the model actually reasons over. It is inferred during inference, from token patterns, conditioned on context. In the terms of the founding post, P is enforced and R is inferred, and the security consequences follow from which side of that line a given piece of structure sits on.

I deliberately call P a representation and not a reality, even though the title of this essay uses the larger word. The model has no access to the world. It has access to what the system put in front of it, and P is already a choice made by the application about how to present things. What matters for security is not whether P matches the world. That is the application's problem, and a classical one. What matters here is the newer problem: whether R matches P.

The failure condition is one line:

R ≠ P

Here, R ≠ P denotes a mismatch in structure the task requires the model to preserve, not a difference in encoding or level of detail. Whether that mismatch becomes a security issue depends on the threat model and its downstream consequences.

The model can then reason coherently, follow every instruction it was given, respect every policy it was trained on, and still produce the wrong result, because the representation it is reasoning over is not the one the system presented. Securing downstream reasoning alone does not guarantee that the representation it operates on is correct.

R ≠ P is six inequalities

The abstraction becomes useful at the point where it stops being one comparison. R is not a single object. It has components, each of which the model has to settle, and each of which can diverge from P on its own:

Each row is a different security question. Each has its own experiment: you vary one thing in P and watch whether that one component of R moves. Each suggests different controls to test: validating model-generated records against P for objects and boundaries, and preserving and checking source and privilege information for roles, provenance and authority. Establishing P through deterministic parsing does not by itself guarantee that the model preserves it. And each has its own threat model, because the attacker who can inflate a count is not necessarily the attacker who can reassign authority.

That is what "localize the failure" means in practice. Instead of "the model got confused", the question becomes: at which component did R diverge from P, and did everything downstream of that component behave correctly given the divergence? In the cases I have documented, the answer to the second half is usually yes: the observed outputs were consistent with the reconstructed representation. They were consistent with the wrong R.

It also explains a pattern in how these findings are received. A defense built for the roles component, which is where prompt injection lives, has no reason to notice a failure in the objects component. A vendor taxonomy built around behavior has no row for a count that is wrong. Neither is a sign that the defenders are careless. They are looking at a different inequality.

What would make this useless

An abstraction that cannot be wrong is not doing any work, so here is how this one could fail.

The decomposition earns its place only if failures actually localize. If it turned out that any manipulation of P that moves one component of R always moves all the others, if you cannot inflate a count without also reassigning roles and authority, then the six rows collapse back into one and the table above is a presentational convenience rather than a model. That would be a real result, and it would push the right framing back toward a single reconstruction failure with several symptoms.

The evidence so far points the other way, and I hold it loosely. The published experiments manipulate objects and boundaries while leaving roles intact: the fabricated records carry no instructions and none are followed. The instruction case manipulates roles while leaving the count intact. And in preliminary probing work, described with its caveats in the perception essay, a probe trained on one failure family did not transfer to the others. The abstraction predicts distinguishable failure patterns, not necessarily separate internal representations. The probing results are preliminary evidence consistent with that distinction, but they do not establish its mechanism. Causal interventions would provide a stronger test of whether the detected signals contribute to the failures.

A second test is whether this distinction adds explanatory or practical value. If separating reconstruction from downstream reasoning does not help us design distinguishing experiments, predict failures, or select different controls, then the abstraction adds little beyond existing descriptions. Reliable detection from outputs would reduce the need for additional defenses, but would not by itself turn a security failure into a quality issue.

What it buys

Nothing in this essay makes a model safer. It makes a question askable.

Before the abstraction, a wrong answer from a model is a wrong answer, and the available responses are to prompt harder, filter more, or pick a bigger model. After it, a wrong answer has a location: it either diverged at reconstruction, on a nameable component, or it did not, and the fault is downstream in reasoning or action. Those call for different experiments and different fixes, and the first of them calls for fixes that do not touch the model at all, because P was known to the application before the model ever saw it.

That is the practical content of an otherwise philosophical claim. Securing reasoning is not sufficient if the reasoning is already operating over the wrong world, and you cannot tell whether it is until you have a name for the step where the world gets built.