IBM’s LLMON Tries to Put a Boundary Between Instructions and Data

An agent reads a web page, finds a sentence telling it to ignore its user and reveal a secret, then has to decide which text is an instruction and which text is merely data. Today, both arrive as tokens in the same context window. IBM’s LLM Object Notation, or LLMON, tries to make that distinction explicit to the model instead of relying on formatting conventions and learned guesswork.

IBM announced two experimental Granite 4.1 previews, at 3B and 8B parameters, alongside a toolkit and examples. The format uses reserved special-token delimiters around semantically labeled components. Unique identifiers can bind a specific instruction to the data it should operate on, much like a function call associates an operation with its arguments. The team says this can reduce unrelated passages and injected instructions from taking control of a response. ^[1]

Why ordinary formatting is a weak signal

A language model processes a prompt as a sequence of tokens. A JSON object has clear structure for a parser, but to a model, braces and quotation marks are also ordinary learned tokens; a quotation mark in a document can resemble a structural delimiter. Long nested structures additionally require the model to track relationships across a long sequence. IBM’s argument is that explicit special tokens and local tags make the roles and boundaries easier to learn. ^[1]

LLMON does not replace the chat template that distinguishes system, user and assistant turns. It adds another layer inside those turns: which pieces are instructions, which are data, which requirements govern a result and how those parts refer to one another. The project also offers conversion utilities intended to translate existing JSON without losing its represented structure. ^[1]

That separation addresses an important failure mode. A retrieved email or document may contain text that looks like a command. If the application gives the model that content beside trusted instructions, the model must infer the intended authority from context. A format that marks the document as data and binds the user’s instruction to a particular data identifier gives training a more explicit pattern to follow.

What the evaluation says—and does not say

The accompanying paper describes post-training Granite 4.1 3B and 8B models with a 4.6-billion-token structured corpus, followed by supervised fine-tuning and reinforcement learning. The authors report indirect prompt-injection attack success falling from a 53–100 percent range for comparison models to 0.02–5.6 percent for LLMON models on their selected evaluations. They also report preserved general capabilities relative to the base models. These are results from the authors’ own experimental setup, not independent replications or a guarantee for a deployed agent. ^[2]

The paper itself gives an important qualifier: direct attacks and multi-turn attacks remain substantially harder. The format does not make malicious input disappear. A compromised system prompt, a developer mistake, a model that ignores delimiters, a tool with excessive permissions or an instruction hidden in a sequence of events can still create risk. The right reading is that training the model to respect structured boundaries may reduce one class of failure, not that the application has acquired a formal security boundary.

This distinction is familiar from web security. HTML escaping helps preserve the boundary between code and data, but it does not decide whether a logged-in user is authorized to transfer money. LLMON may help the model understand the application’s intended semantics; it cannot independently enforce what actions the agent is permitted to take. OWASP continues to recommend layered defenses for prompt injection, including least privilege and human approval for consequential actions. ^[4]

Where a team can test the idea

The previews are useful for teams building retrieval or tool workflows that can express clean object boundaries. Start with a non-production harness and one narrow task: ask the model to extract a value from a document while ignoring instructions embedded in the document. Compare structured and unstructured prompts against the same adversarial cases, including benign quoted commands, nested content, conflicting documents and multi-turn attempts.

Measure more than attack success. Track whether the model follows the correct instruction, extracts the correct data, refuses when the task is ambiguous, produces schema-valid output and maintains quality on ordinary inputs. A defense that blocks attacks by refusing everything is not operationally useful. Record the exact model checkpoint, tokenizer, template, conversion library and evaluation set; formatting details are part of the system under test.

Keep the actual enforcement outside the model. Give a summarization agent no write access. Use a narrow function that validates arguments and checks authorization independently. Do not put durable secrets into retrieved context. Require approval for payments, deletion, public posting or access changes. Treat model interpretation as one layer that can fail, and let deterministic checks prevent a failure from becoming an external action.

LLMON’s central idea is a valuable interface question: can systems communicate the difference between instructions and evidence in a way that models learn more reliably? The early results make that worth testing. The security claim only becomes meaningful when a team measures the complete agent, including its tools, permissions and recovery path, against attacks that resemble its own environment. Our guide to prompt-injection boundaries for agents covers the complementary application-level controls.