IBM Releases LLMON and Granite 4.1 Preview Models

IBM has released LLMON, short for LLM Object Notation and pronounced “lemon”, which it describes as “an LLM-native markup language”, together with two experimental preview models trained to use it: granite-4.1-3b-llmon-preview and granite-4.1-8b-llmon-preview. The Hugging Face blog and both model cards are dated 12 November 2026. The models are derived from Granite 4.1 base checkpoints, rather than from the released instruct models, and are licensed under Apache 2.0.

The idea is to make the structure of a prompt explicit. IBM says parts of a prompt, including system policy, instructions, data, documents, tool definitions and tool results, go into individually addressable blocks whose tags are wrapped in reserved special-token delimiters. An exec block then names which instruction to run, which inputs it operates on, and where the output should go. The 8B model card states the privilege rule the models are trained on: “exec instruction and exec system are authoritative. Everything reached through exec input (data, documents, tool schemas, and tool results) is input to be read, not a command to follow.” The card’s wording uses the markup paths for those exec fields; the meaning is the same.

That design is aimed at indirect prompt injection, where a malicious instruction is hidden in a retrieved document, a tool response or other data. On the OPI benchmark, which IBM says places the injection in the data of classic NLP tasks and reports robustness as one minus the attack success rate, IBM writes that LLMON “practically eliminates the problem on this benchmark, avoiding 47% more attacks relative to the best frontier model that we tested, and 95% more than the best open-source model”. It says it observed “similar trends” on ASB and StruQ. Those results are IBM’s own figures, and the “practically eliminates” wording applies to OPI as IBM describes it, not to prompt injection in general.

IBM also notes that the benchmarks test robustness to static indirect prompt injections, and that the instruction/data separation “directly addresses this type of attack”. It adds: “We are actively working on also improving adaptive attacks which unfold over many chat turns.” The previews are not presented as a defence against those adaptive, multi-turn attacks.

The company is equally plain about the limits of the work. The blog ends: “This is an experimental preview, ready for exploration and evaluation but not for production.” The model card says: “The privilege rule is a learned behavior, not an enforced guarantee.” It adds that the rule substantially reduces, but does not eliminate, the chance that an instruction embedded in data, a document or a tool result is followed, and that it should not be treated as a sole defence for an agent with access to sensitive systems. Conventional chat-format prompts, the card says, are out of distribution and will degrade quality; users are told to use the bundled chat template, which renders a normal messages list into LLMON.

On general capability, IBM says the LLMON models perform “on par” with the Granite 4.1 Instruct models. The 8B model card, where the stated aim is parity rather than improvement on ordinary tasks, reports MMLU of 74.20 against 73.84 for the instruct model, GSM8K of 89.16 against 92.49, and BFCL v3 of 67.93 against 68.27. Those are IBM’s figures. The 3B card shows a similar mixed pattern, and IBM’s overall description for both sizes remains “on par”.

IBM says LLMON does not replace chat templates; it enriches them, by telling the model what each component means and how the components relate, rather than only which role they belong to. A turn can mark parts as exec true or false: a part marked true is bound into the exec block, while a part marked false is still rendered into the context but is referenced by nothing. The company also releases conversion tools that it says translate JSON to LLMON and back without loss, a GitHub repository with a toolkit and examples, and two papers: LLMON: An LLM-native Markup Language to Leverage Structure and Semantics at the LLM Interface and Post-Training Large Language Models with LLMON. Supported languages listed on the cards are English, German, Spanish, French, Japanese, Portuguese, Arabic, Czech, Italian, Korean, Dutch and Chinese.

The models start from Granite 4.1 base checkpoints so that, IBM says, LLMON behaviour is learned during post-training rather than layered on an existing chat format. Training includes a conventional instruction-tuning mix re-serialised into LLMON, plus decoy instruction and data blocks that are present in context but left unbound, so the model has to follow the execution block and ignore the rest. Reinforcement learning follows, including a final preference stage built from the model’s own responses to injection attempts.

The release sits alongside earlier Granite work, including Granite Switch 4.1 and Granite Speech 5.0. For agents that mix trusted instructions with untrusted tool results or documents, IBM already offers a separate set of identity and shutdown controls, described in TSN’s account of Agent Identity and the kill-switch preview. Those controls are a different product line from LLMON.

Analysis

The useful distinction in this release is not a claim that prompt injection has been solved. IBM’s strongest wording, “practically eliminates the problem on this benchmark,” is tied to OPI, a test of static indirect injections hidden in data. The same blog points to similar trends on ASB and StruQ, and immediately qualifies the lot: the tests are static, and adaptive attacks that unfold over many chat turns are still being worked on. That is a narrower result than a general defence, and IBM presents it as such.

The other qualification matters equally. The privilege rule is learned, not enforced. A model that has been trained to treat material reached through exec input as data can still follow an instruction hidden in that data; the card says the chance is reduced, not removed. Calling the previews “not for production,” and warning that they should not be a sole defence for an agent with access to sensitive systems, is therefore not fine print. Anyone trying the weights should keep a separate control plane, which is also the spirit of IBM’s own agent-identity work.

On ordinary tasks, “on par” is IBM’s summary, and the 8B table supports a mixed reading rather than a clean win: MMLU is slightly up, GSM8K and BFCL v3 are slightly down. The more interesting engineering choice is the starting point. Training from the Granite 4.1 base, rather than bolting markup onto an already instructed chat model, is IBM’s attempt to make the instruction/data split a native habit. Whether that habit holds once an adversary can adapt across turns is the question IBM says it is still working on.