Steganographic Language Output Process encoding

15 min read Original article ↗

Author: Aaron P. MacSween

Published: 2026-07-26

Dear reader,
in the following article I will present a hypothetical, completely untested application of Large Language Models (LLMs) for the purpose of steganography (the practice of hiding information in plain sight) which I will refer to as SLOP-encoding. I am not endorsing the broader usage of LLMs, nor do I intend to reinforce the belief that they are intelligent in any meaningful sense of the word. Smaller language models like BERT or even a humble Markov chain are theoretically capable of serving the same purpose, albeit with reduced efficacy, so it should still be possible to employ this technique while avoiding most of the negative externalities associated with modern LLMs. I'm writing this mostly because I unexpectedly stumbled into what might be a novel algorithm which I believe could have some compelling implications. Continue reading for the details.

Drawing inspiration from fiction

Our story begins with my friend Mythreyi sending me a screenshot from the 2024 TV series The Agency, basically asking whether the tech was plausible or just the usual TV hacker nonsense ™:

Two different messenger UIs are shown side-by-side on a computer screen.
On the left: Thanks for dinner! I got 2 glasses of wine and the shared appetizer for the table.
On the right: Target has access to data relevant to selection of zone suited to burying nuclear material.
It is implied that the message on the left has been derived from the one on the right.

I haven't seen the show, so I'm missing some context, but it looks like the scene's character (some sort of spy) has typed a message about nuclear material on the right and had it automatically converted into an innocuous message about their dinner on the left. The tool seems to be branded as ENCRYPTO, to make it clear to the audience that their message is being hidden with fancy tech. So what's going on here?

The way encryption generally works is that you have some unencrypted data (the plaintext) and you transform it into the encrypted data (the ciphertext) with the use of some fancy math and a secret key. In the case of symmetric encryption, it's assumed that the recipient of the message will use the same key to reverse the process, decrypting the ciphertext back into its plaintext form. Ciphertext generally comes out garbled, however, as it's intended to be indistinguishable from noise. This makes it obvious that something is encrypted.

What seems to be shown in this scene is the conversion of plaintext into steganographic cover text, which superficially resembles natural language but actually encodes some hidden signals. My immediate response was that I was not aware of any systems that function exactly like this. I know of methods to hide arbitrary messages in unicode, but that can be detected by automated methods, so I certainly wouldn't opt for that if I wanted to avoid suspicion from a sophisticated adversary. There's also the problem that the cover text is shorter than the hidden plain text, which is not what I'd expect. The hidden text in the screenshot is somewhat compressable, so it might be possible, but at a glance this definitely looked like TV hacker nonsense™.

I went away and thought about the problem for a while, then realized how it might be possible using LLMs and some low-level trickery.

The basics of LLMs

Unless you've been in a coma for the majority of the past decade you'll have likely heard about Large Language Models. They exhibit complex behaviour, but the way they operate can be reasoned about without too much difficulty, at least at a high level.

First, they convert text input into tokens, which are small chunks of text represented as whole numbers. This is done with a tokenization algorithm, which generally have a fixed vocabulary size. For example, Byte-pair encoding has around 100,000 possible tokens, each of which is identified by an integer.

LLMs are typically split into two parts: the code which is actually run, and the weights which represent the strength of connections between many layers of simple neuron simulations. I'm intentionally skipping over a lot of detail here, but the training process adjusts the strength of these network connections until they do a good job of predicting the probability that any given token will occur next in a given sequence. Most of those tokens will have a probability of zero (or arbitrarily close to it) in any particular circumstance, while a few tokens will be much more likely. For instance, if you see a "q" in some English word, there is a very good chance that a "u" will come next.

You can then choose from among the most likely tokens, append it to the sequence, and repeat the process for as long as you like. When you convert the tokens back into text, you should end up with a phrase that could plausibly have occurred in the language model's training data. The resulting text will be wrong a significant percentage of the time, but in general it should exhibit the same grammatical structures as the inputs on which the model was trained.

The fact that LLMs model language and not the world is a problem if you intend to rely on them to output facts. They are, however, quite appropriate for the purpose of producing plausible streams of steganographic cover text.

Naïve slop-encoding

The usual method of generating text with LLMs involves some randomness. Random number generation is a complex topic that deserves a nuanced treatment, but I've written extensively extensively about the topic before and would prefer to gloss over it today. As far as this article is concerned, the important thing is that LLMs are inconsistent. The next token in any sequence (which I'll hereafter refer to as a successor for brevity's sake) is chosen from a set of likely tokens, but the outputs of different runs can diverge wildly even with the exact same input text.

It's worth noting that this is a design choice rather than a fundamental property of LLMs. Any given model's internal probabilities are determined during training and remain fixed during their operation. There is nothing to stop us from using an LLM to generate text in a purely deterministic fashion. We could choose to use a Pseudo-Random Number Generator (PRNG) with a known seed, or simply choose the most probable successor at each iteration with a stable sorting algorithm to break ties. For the purpose of the steganographic method I'm proposing, I'll use the latter approach.

If we always choose the best successor, then any two people who prompt identical language models with identical text will arrive at identical results. We can exploit that behaviour and encode information by deviating from the expected sequence of tokens. For instance, I could use the best successor to represent a 1 and choose any other token to represent a 0, and in this fashion encode arbitrary binary data into the LLM's output.

To decode the hidden values, anyone receiving this cover text would input a pre-agreed prompt, observe deviations at each step, and restore the stream of bits into its original format, which would presumably be some text as in the scene from The Agency. This is superficially similar to the use of a codebook, however, the attention mechanism that is inherent to LLMs makes the code highly context-dependent and more dynamic than a physical codebook could ever be.

I described this scheme to my friend and frequent collaborator (Charles Meyers, PhD.), comparing it to how we send radio signals by modulating a carrier wave's amplitude (for AM radio) or frequency (for FM). I found that I needed a short name for the technique, and naturally came up with slop-encoding, but I considered that this might not be suitable for publishing in formal literature. After some back and forth, we arrived at Steganographic Language Output Process (SLOP-encoding) as a somewhat more professional term.

Limitations

There are some constraints, of course. Such a system could only be built with a deterministic tokenizer, since the decoder would need to be able to transform the received text back into the exact same intermediary tokens that were produced by the transmitter. Any ambiguity in this round-trip process could yield entirely different plaintext, which is unacceptable for our purposes.

Likewise, we might encounter cases where there is only one valid successor (which I'll refer to as a constrained successor). No information can be encoded in these cases, so our codec would have to support a variable bitrate. In practice this would allow us to transmit approximately 1 bit of information per token, minus some indeterminate error rate due to constrained successors. By my estimation, this would result in cover text that was around 16 times more verbose than the fictional system depicted in our reference scene from The Agency when given the same plaintext.

Fortunately, this description was only intended as a sort of toy example to convince readers that the approach is viable. We can do better.

Optimizing for throughput

The proposed system already employs a minimally variable bitrate out of necessity. We can make it more efficient by extending it to encode multiple bits into each token wherever possible.

As noted above, byte-pair encoding has a vocabulary of around 100,000 tokens. In theory, this would be sufficient to carry 16 bits per token. Unfortunately, tokens do not occur with equal probability in natural language, otherwise language models would serve no purpose. In practice, many tokens will have zero chance of occurring in a given context. Encoding this many bits would degrade the resulting text into complete nonsense and defeat the point of our system. This upper bound of 16 bits per token is completely unrealistic, but we should still be able to achieve better than our lower bound of approximately 1.

We can probably strike a balance between our bitrate and the plausibility of the resulting text by setting a cutoff point for probabilities. For example, we could specify not to select tokens which occur with a probability of less than 5%. This would result in a sequence having at most 20 viable successors, allowing us to select from among the top 16, giving us a new upper bound of 4 bits per token.

Lowering this cutoff point to a somewhat smaller percentage would improve the possible bitrate to 5 bits, but each bit of improvement would require us to cut the minimum plausibility threshold in half. Empirical studies on how this affects quality would be interesting, but I would expect a steep rate of diminishing returns. In practice I would consider 4 bits/token to be pretty reasonable.

Many of those tokens would be 2 bytes long, so I'd estimate the resulting cover text to be at least four times as long as ASCII-encoded plaintext. It's a significant improvement over the naive approach, but even if we assume that our text will be compressed before encoding, we can see that the fictional results shown in The Agency were most likely exaggerating the capacity of such a system.

Optimizing for security

Natural language has structure, and codebreakers throughout history have been able to exploit this to detect hidden patterns. For example, scientists have recently had some success in studying the communication of non-human species like orangutans and sperm whales. If I was a spy, I would prefer not to risk my physical safety on the assumption that slop-encoding would resist expert analysis.

So we've taken LLMs, removed their random components, and replaced them with meaningful variation. Now we have to hide that meaning, and the obvious answer (obvious to me, at least) is to add a layer of encryption. My rationale is that modern encryption methods are designed such that their output is indistinguishable from noise, meaning that a zero or one will be equiprobable in each position. Introducing encryption therefore reintroduces the appearance of randomness to an uninformed observer, even if the actual process may be entirely determistic.

The use of encryption will mean that any communicating parties will need to either agree on a shared symmetric key or discover the public component of the other party's asymmetric key pair. Given that they already have to agree on a language model, a prompt, and a token probability threshold, the addition of a key seems manageable to me.

So far, the system's definition looks like this in pseudocode:

covertext = encode(
  model,
  prompt,
  cutoff,
  encrypt(
    compress(plaintext),
    key
  )
);

plaintext = decompress(
  decrypt(
    decode(
      model,
      prompt,
      cutoff,
      covertext
    ),
    key
  )
);

I'm not attached to any particular cipher, but I'd suggest using one which provides authentication. This would introduce some additional data for each message, but it would make it possible to detect forgeries, modifications, and transmission errors. Including a compression step before encryption should counteract this overhead anyway, especially in the case of larger messages.

The techno-socio-political implications of SLOP encoding

I've looked for prior art in the domain of LLM-based steganography, and while I found some proposals, I haven't yet encountered any which are equivalent to this particular method of subverting slop. If any readers are aware of existing work, please let me know and I'll happily update this article to acknowledge them.

The system I've proposed combines language models, cryptography, and steganography, and unless I've made any egregious mistakes, should be capable of encoding arbitrary binary data into a format which is indistinguishable from LLM slop. That relationship works in both directions, so the converse should also be true, meaning that LLM slop is indistinguishable from encrypted data. Assuming that conjecture holds, we can draw some dramatic conclusions.

I assume that a system like this could already exist regardless of whether any work has been published on the topic. Even if the idea remains entirely theoretical at this point, I don't think it would be particularly difficult to implement. If more attention is drawn to the idea, the likelihood that it gets built will only grow.

As long as there is any practical risk that such systems are deployed in the wild, agencies that employ widespread surveillance will need to take their existence into account. Various governments around the world are known to employ a strategy commonly referred to as Harvest Now, Decrypt Later (HNDL). The basic idea is that ciphertexts that are currently beyond their ability to decrypt can be retained for a future date beyond the construction of a Cryptographically Relevant Quantum Computer (CRQC), at which point they could be decrypted.

The widespread availability of a reliable steganographic method for secretly transmitting arbitrary binary data significantly raises the potential cost of the Harvest Now, Decrypt Later strategy. It is already challenging to reliably distinguish slop from human-authored messages, so if secret messages become indistinguishable from slop, then those employing the strategy must therefore be prepared to harvest approximately all human communication. This is at best impractical, and almost certainly impossible.

In the meantime, generative AI slop has become a very significant societal problem. It is much harder to trust online information, the quality of software has steadily declined as coding assistants have been more widely adopted, and corporate enthusiasm for these related technologies has resulted in something like 25% of humanity's equity being invested into activities which are quite frankly disastrous for the environment. So I find it poetic that the open-weight models that have been created due to all this hype might be leveraged against surveillance programs, potentially transforming the slop industry into an unwitting adversary of intelligence agencies.

Going further, if people were to adopt techniques like this for secretly communicating through public channels, that would make it more likely that the corporations working to create LLMs would ingest synthetic data into their future models, helping to accelerate model collapse.

Reflection and possible next steps

I think it is worthwhile to consider that a system like this would necessarily require more computational resources than simple encryption, so there are harms associated with deploying it widely and indiscriminantly. That said, the use of slop purely as a transmission medium does not incentivize the current progression of ever-larger, state-of-the-art models as other applications of slop do.

The LLMs that are available today could be repurposed directly, and in fact, those that were available several years ago might be more appropriate. I can conceive of there being demand for models optimized to run on low-power devices, for much narrower purposes, being trained on small data-sets and using consumer-grade hardware, powered by electricity from renewable sources.

Of course, the only reason any of this might be necessary is because there are people who want to limit the public's access to encrypted communication tools. So they could also just stop that, and there would be little reason for this technology to exist at all.

For now, there is a great deal of literature on the topic which I'd like to continue reviewing. I also intend to work towards some practical prototypes to (hopefully) validate the approach. Maybe I can see about generalizing the approach to other media formats beyond text?

Unlike most applications of generative AI, I don't expect that this idea would attract monetary investment. If I'm wrong about that and you'd like to throw a few billion dollars into my bank account, then I suppose you're welcome to make an offer. Otherwise I'll pursue this as yet another hobby project.