The Model as a Semantic Decoder

The last post covered behaviour hidden inside the model. This one turns it around. What about information hidden in the things the model reads, information a person would miss but the model would pick up straight away?

This is the part of the threat model I find most interesting, and the part most security reviews are not set up to catch.

A spreadsheet with more in it than you think

Take an ordinary workbook. On screen it shows one sheet of figures. Underneath, it might also have hidden sheets, hidden rows, comments, metadata or embedded objects. A person opening it in a spreadsheet app sees the visible sheet and moves on.

An LLM processing the same file gets all of it. It can find the hidden content, make sense of it, and act on it. It might remove flags, change values, or write instructions based on something nobody else in the room knew was there.

Nothing was decrypted and nothing was exploited. The information was already in the file. The model just read it more completely than a person would.

Encoding is not encryption

It helps to be precise here. Strong encryption is designed so that nothing meaningful can be recovered without the key, and an LLM cannot defeat sound encryption by staring at ciphertext. That is not the threat.

The threat is information that is:

• Encoded rather than encrypted.
• Obscured inside a document or data structure.
• Split across several fields or locations.
• Disguised as ordinary configuration or metadata.
• Only meaningful when combined with the surrounding context.
• Written in a convention the model has learned to recognise.

Simple encodings like Base64 or hex are not the hard case. Scanners already flag those. The hard case is content whose meaning depends on semantic interpretation. It looks like a normal config value or a normal note, and it only turns into an instruction once something that understands language reads it in context.

The model as decoder

When that happens the model is acting as a semantic decoder. What it decodes does not have to be code or a command. It could be a description of desired behaviour, or data the model turns into a tool request or a script.

At a high level the sequence looks like this:

1. A plugin or document supplies data that looks harmless.
2. The agent reads or processes that data.
3. The model recognises a meaningful pattern or instruction in it.
4. The model folds that into its reasoning about the task.
5. The model generates a tool request, code or other actionable output.
6. The framework executes it, if its permissions allow.

Notice that the plugin in step one may have no software vulnerability at all. This is a model mediated interpretation problem. The plugin's code is fine. Its data is the issue.

Related, but not the same thing

Several existing ideas overlap with this:

• Steganography: hiding information inside another file or data stream.
• Instruction concealment: presenting instructions in a form a human reviewer would not recognise.
• Indirect prompt injection: feeding instructions to the model through external content it processes.
• Neural backdoors: learned conditional behaviour in the weights, as covered in the last post.
• Polyglot and malformed documents: files that different tools or layers interpret differently.

These are not interchangeable. A hidden sheet is not automatically a prompt injection, and an encoded instruction is not automatically a backdoor. The real risk is when they combine. Picture a model with a learned trigger, reading a document that quietly supplies the rest of the condition, inside an agent that can act on the result.

Plugins have two sides

Inference frameworks commonly support extensions of various kinds: model plugins, platform plugins, logits processors, IO processors, custom operators and attention backends. Each one is a piece of the software supply chain, and many of them have both a host side and a GPU side. Those two sides are very different from a security point of view.

Host side code, the Python or C++ loaded into the inference process, generally runs with that process's operating system permissions. Depending on the deployment that can mean:

• Files the process can read or write.
• Environment variables and credentials.
• Network connections.
• Anything else the container or host allows.

A malicious host side plugin does not need to break GPU memory isolation to get at any of that. It is already inside the process.

GPU side code is more contained. A CUDA kernel works within the memory and execution environment the CUDA runtime gives it. It does not automatically get access to host memory, other processes or unrelated GPU allocations.

So a plugin is not one security boundary. It is two, with very different reach. In practice the more immediate risk is usually the boring one: a trusted host process loading untrusted extension code.

What inspection has to change

Traditional security review looks at executable code, dependencies and known file formats. That is not enough when the component consuming the content is an LLM. A plugin can contain almost no code and still supply information that changes what the model does.

Review now has to ask two questions:

1. What can this plugin execute?
2. What can this plugin cause the model to interpret, generate or request?

The first one we know how to answer. The second is much harder, because the answer depends on the model, the prompt, the surrounding documents and the tools available. You cannot answer it by reading the source code.

What's next

Three posts in, the picture is a model you cannot fully verify, reading content you cannot fully inspect, inside a framework that can act on what it decides. The final post is about what to do about that. The short version is that you stop asking the model to be the safety layer. Read part four.