IBM's LLMON: Can AI Tell Instructions Apart From the Documents It Reads?
- AI
- Guides
- Granite
- Prompt injection
- AI research
- Written by
- Bhargav Tibadiya
- Published
- Reading time
- 8 min read
IBM's LLMON tries to make a model's context less ambiguous by marking instructions, data and requirements as different kinds of material, then explicitly connecting the parts that belong together. The November 12 release includes experimental Granite 4.1 3B and 8B preview models trained for that format. It is not a claim that adding XML-like tags to an ordinary prompt solves prompt injection[1].
The most interesting result is better resistance to indirect prompt injections in the reported evaluations. The most important limit is just as clear: these are static-attack benchmarks, the separation is learned behavior rather than an enforced guarantee, and IBM calls the release ready for exploration and evaluation, not production[1].
This article explains the design and its limits from the release and repository. I did not run the models or reproduce the security evaluations.
Why a document can become an instruction problem
An assistant may need to summarize a page, compare documents or use a tool's result. Those materials can contain sentences that look like commands. The application wants the model to read those sentences as content, not let them take over the task.
That is the central problem of indirect prompt injection: a command arrives inside material the model was supposed to inspect. It may appear in an otherwise ordinary document or retrieved result. The attacker's wording does not become authorized simply because the application retrieved it.
Ordinary text prompts often leave the model to infer which passages are instructions, which are quoted data and which requirements apply to which source. Long context makes that inference harder when many tasks and results coexist.
LLMON makes those relationships explicit. That is a research direction for clearer model inputs, not a substitute for deciding what a system is allowed to do.
What LLMON adds to the context
LLMON stands for LLM Object Notation and is pronounced “lemon.” IBM describes it as XML-like markup with reserved special-token delimiters, semantic tags and unique block identifiers. An execution block names an instruction, its inputs, its requirements and the destination for the answer[1].
The difference from decorative tags is the combination of tokenizer support and model training. The model sees boundaries that have dedicated tokens, and has been trained to interpret the marked relationships.
For an illustrative example, an application might ask a model to summarize a supplied report in under 100 words. The task, report and length requirement are separate components. The binding says which instruction operates on which document under which requirement, rather than flattening everything into one paragraph.
A sentence inside the report remains report content. That is the intended interpretation. Whether the model maintains it against a particular attack remains something to test.
Why IBM compares the format with JSON
JSON is excellent for ordinary programs that use a parser to validate and read structure. IBM's argument is narrower: a causal language model sees tokens, and the textual punctuation used to encode JSON also appears inside ordinary content. Escaping and nesting that are precise for a parser can still be difficult for a model to follow over long spans[1].
LLMON uses separate structural delimiters and states nesting locally. The release also includes converters intended to preserve existing JSON structure when moving into and out of LLMON.
That does not make JSON obsolete or insecure as a data format. A program can still parse and validate JSON deterministically. The question is how best to present structured material to a model, not whether developers should abandon their existing application interfaces.
The repository provides tooling and examples for this translation layer. It is a source of implementation guidance, not independent proof of the release's performance claims[2].
It enriches chat templates rather than replacing roles
The preview models ship with their own chat template. Developers can still build a messages list, but a turn can name separate instructions, data and requirements. The template renders the addressable blocks and the execution binding described by the release[1].
That matters because there are two levels of structure. A chat role identifies a speaker or part of a conversation. LLMON adds information about what a component means and how it relates to other components, including parts within the same turn.
The application still has to supply the right relationships. If a developer incorrectly marks hostile document text as the instruction to execute, a well-structured format does not repair that authorization error.
Likewise, a converter cannot decide which person has permission to request an external action. Representation can make a boundary easier for a model to learn; it cannot establish the policy or identity behind that boundary.
The reported gains concern static indirect attacks
IBM evaluates the previews on OPI and reports similar trends on ASB and StruQ. The release defines robustness as one minus attack success rate: the share of attacks where the model does not carry out the injected instruction[1].
It reports large improvements and near-zero attack success for some benchmark settings. Those results should stay attached to the benchmark, models and attack setup rather than turning into a blanket claim that prompt injection is solved.
The authors explicitly distinguish static indirect injections from adaptive attacks that unfold over multiple turns. They say work on adaptive attacks is continuing. A fixed collection of attacks does not establish what happens when an adversary repeatedly changes tactics after observing failures.
Unite.AI's reporting also presents the release as an experimental approach to resistance, rather than a production security guarantee. That is outside coverage, not an independent replication of the evaluations[3].
Learned separation is not a hard security boundary
The release calls the behavior learned, not enforced. That phrase is central to interpreting the result. A model trained to ignore unbound instructions may usually do so without providing the kind of absolute isolation an operating-system permission check is intended to enforce[1].
For an application, the sensible response is to keep ordinary controls outside the model: narrow tool permissions, validation of inputs and outputs, explicit approval for consequential actions and records that let you inspect what happened.
A model can recommend an action without being allowed to execute it. It can extract information from a source without being allowed to send that source elsewhere. These distinctions remain useful whether the context uses LLMON, JSON or plain text.
The guide to checking an agent's final state addresses a related gap: a plausible answer is not proof that the work happened correctly. A stronger input representation does not remove the need to inspect effects.
Training is part of the claim
IBM says the previews start from Granite 4.1 base checkpoints, rather than adding a new wrapper to the released instruct models. Its training process re-serializes instruction-tuning material into LLMON, includes unused decoy instructions and data, and follows with additional training stages[1].
The purpose of the decoys is to teach the model to follow the specified dependencies and ignore irrelevant material. This helps explain why copying the visible markup into an unrelated model is not an equivalent intervention.
The release reports general capability close to the Granite 4.1 Instruct models on its chosen benchmark categories. That is encouraging for the research question, but it is not a guarantee that a specific application will preserve quality after switching models.
Evaluate ordinary tasks alongside adversarial ones. An assistant that resists an attack but loses required facts or refuses legitimate work may still be a poor fit for a particular workflow.
Context structure is different from token compression
LLMON is primarily about making meaning and relationships explicit to a model. That is not the same goal as reducing the size of a prompt or finding the cheapest serialization.
A format can add useful structure while increasing tokens in some cases. Conversely, a short representation can omit distinctions that matter for instruction following. Neither token count alone nor a security benchmark alone answers whether the full workflow improves.
The separate LLM token-usage guide deals with context volume and cost. LLMON's release asks a different question: can a model more reliably identify which instruction applies to which material?
Keep those goals separate in an evaluation. Record token usage, answer quality, attack outcomes and latency instead of treating one favorable number as a complete verdict.
How to evaluate the preview without overstating it
Begin in an isolated test environment with no real external effects. Choose ordinary tasks where the right output is known, then add document content that conflicts with the intended task. Keep the authorized instruction fixed so you can tell whether the output changed for the wrong reason.
Compare the conventional and LLMON paths on the same data and requirements. Preserve model versions, templates, bindings and evaluation criteria. Include missing information, irrelevant text and long documents, not only a few obvious attacks.
Then test attacks that vary after a failure, and cases where the application's own binding is mistaken. Those checks answer different questions: model resistance, adaptation and application policy errors should not collapse into one success rate.
This is a proposed evaluation plan, not a benchmark I performed. IBM's own status remains the appropriate starting point: an experimental preview for exploration, not a production recommendation.
FAQ
What is IBM's LLMON?
LLMON is LLM Object Notation, a model-oriented markup format that separates semantic components and explicitly binds instructions to inputs, requirements and output destinations. The preview models are trained to use that structure.
Which models were released?
IBM announced experimental granite-4.1-3b-LLMON-preview and granite-4.1-8b-LLMON-preview models derived from Granite 4.1 base checkpoints, together with tools and examples.
Does LLMON solve prompt injection?
No. The release reports strong resistance on static indirect-injection benchmarks, but distinguishes those tests from adaptive multi-turn attacks and calls the separation learned behavior rather than an enforced guarantee.
Can I get the same protection by adding XML tags?
The release does not establish that. Its results involve reserved tokenizer delimiters, a specific representation and models trained for that representation, not ordinary decorative tags added to an unrelated model.
Does LLMON replace JSON?
No. The project includes conversion tools for existing JSON pipelines. Its claim concerns how structure is communicated to a model, not whether applications should stop using deterministic JSON parsers and validation.
Is the preview ready for production?
IBM explicitly labels it experimental and suitable for exploration and evaluation, not production. This article did not run the models or reproduce their security results.
