APPLY NOW

Special Token Injection in Operational Technology: How LLM Integrations Can Create Real-World Industrial Risk

Cyber Academy
12 May 2026 — 10 min read

Special Token Injection in Operational Technology

Summary

Special Token Injection (STI) is an attack on the structured layer of an LLM prompt: the control tokens and role markers that tell a model who is speaking and what counts as instruction versus data. Where ordinary prompt injection tries to talk a model into misbehaving, STI tries to forge that underlying structure directly. This article looks at what STI means once LLMs move into Operational Technology (OT), where a manipulated output is no longer just bad text but can shape maintenance decisions, alarm triage, incident response, or operator guidance. It covers how STI works, why OT raises the stakes, four concrete OT scenarios, and the defensive practices organizations should put in place before an incident forces the issue.

A lot of people are still underestimating how strange the LLM attack surface really is.

In traditional security work, we are used to reasoning about boundaries. We ask where input ends, where code begins, what gets sanitized, what gets executed, and which component is allowed to do what. With LLM systems, those boundaries are far less stable than they look. A chat window feels simple on the surface, but underneath it sits a prompt-construction pipeline full of roles, templates, control markers, tool wrappers, and tokenization rules. That is precisely where things start getting interesting from an attacker's perspective.

One of the cleaner examples of this is Special Token Injection, or STI.

Academic work had already made a related case: Zhou et al.'s Virtual Context paper showed that special-token-based attacks can materially improve jailbreak effectiveness across models. Sentry Cybersecurity's 2025 write-up later took the same underlying idea and framed it through a pentester's lens, helping make the issue more concrete for practitioners.

What makes STI especially worth examining, though, is not just that it can break a chatbot. It is that the same weakness starts to look very different once LLMs are placed inside Operational Technology environments. In OT, a compromised LLM output is no longer just bad text. It can become bad prioritization, bad maintenance planning, bad incident interpretation, or bad operational advice in systems where the downstream effects are physical.

This article is not a rehash of STI as a general LLM issue; it focuses on what STI means once LLMs are placed inside OT workflows.

What Special Token Injection Is

At a high level, Special Token Injection is an attack against the structured prompt layer of an LLM system.

Modern chat-based models do not actually “see” a conversation the way users do. Under the hood, the application usually converts messages into a serialized token sequence using model-specific control markers. Hugging Face's documentation is very explicit about this: chat systems are still just token sequences, and roles such as user, assistant, and system are represented through control tokens like <|user|>, <|assistant|>, [INST], or similar delimiters depending on the model family.

Those markers are not decorative. They tell the model how to interpret the prompt structure.

That is where STI comes in.

As described by Sentry Cybersecurity, STI exploits reserved tokens or keywords in an LLM's structured prompting protocol in order to manipulate how the target model interprets the conversation. In practical terms, that means attacker-controlled content may try to introduce control strings such as:

  • role delimiters
  • message-boundary markers
  • tool-call wrappers
  • sequence terminators
  • model-specific prompt tokens

If those strings survive preprocessing and are interpreted as structure instead of harmless text, the model may no longer treat the attacker input as ordinary user content.

That is the core idea.

Why STI Is Different From Ordinary Prompt Injection

A lot of prompt injection is linguistic. The attacker writes something like “ignore previous instructions” and hopes the model follows it. STI is more structural.

Instead of only arguing with the model in natural language, STI tries to interfere with the formatting layer that tells the model who is speaking, what role they have, and whether a block of content is part of the prompt, a tool call, or the start of an assistant response.

That distinction matters.

Persuading the model is attacking behavior. Tampering with the prompt structure is attacking the application's assumptions about authority.

This is one reason the issue is so uncomfortable from a security perspective. The attack is not always against “the model” in isolation. It often sits at the boundary between:

  • the application
  • the chat template
  • the tokenizer
  • the orchestration layer that interprets outputs

If the tokenizer or inference pipeline does not properly escape or filter special sequences, attacker input can reach the model as a structured payload containing forged role segments or tool instructions.

How STI Works in Practice

The easiest way to think about STI is to walk the pipeline.

A typical LLM application does something like this:

  1. It takes user or external input.
  2. It wraps that input into a message structure such as system, user, assistant.
  3. It serializes the messages through a chat template.
  4. It tokenizes the result.
  5. It sends the final token stream to the model.

Hugging Face's docs show this explicitly. A chat may be transformed into a sequence containing markers like <|system|>, <|user|>, <|assistant|>, or ChatML-style boundaries such as <|im_start|> and <|im_end|>.

Their tokenizer docs also note that special tokens are handled differently from ordinary text and “are never split” by the tokenizer when registered as special tokens.

That means control strings matter.

If an attacker can inject content that prematurely closes one message and opens another, the prompt that finally reaches the model may no longer match what the developer thought they sent. Instead of:

user says X

the effective structure may become:

  1. user says part of X
  2. forged system instruction says Y
  3. forged assistant/tool segment says Z

This is why STI is best understood as a parsing-layer problem. It is not just the model being “too obedient.” It is the pipeline failing to preserve the difference between content and control syntax.

Why Security People Should Care

STI also fits a pattern security researchers have seen before: complex systems quietly turning data into instructions because the boundary was weaker than everyone assumed.

But there is also an important difference. The UK NCSC made this point clearly in December 2025: prompt injection is not SQL injection in any simple sense, because LLMs do not truly enforce a hard separation between instructions and data. Under the hood, there is only token continuation, not a reliable security boundary. Liu et al.'s benchmarking work on prompt injection attacks and defenses reached a similar conclusion from the empirical side: existing defenses reduce the problem but do not reliably close it across models and tasks.

That means there is no comforting “just parameterize it” answer here.

And that is exactly why STI matters in OT.

Once LLMs move into alarm triage, predictive maintenance, engineering search, or industrial incident interpretation, even a structurally manipulated output can influence high-trust workflows. A poisoned answer in an enterprise chatbot is annoying. A poisoned answer in an operational workflow can become a reliability, safety, or process-integrity problem.

Why OT Changes the Threat Model

This is where the conversation gets much more serious.

In most mainstream discussions, prompt injection is framed as a problem of bad outputs, leaked system prompts, or unauthorized tool use. Those are real concerns, but they are still often discussed inside an IT-centric mental model. The failure mode is assumed to be a compromised chatbot, a broken workflow, a data leak, or an automation mistake inside a business process.

OT does not give us that luxury.

Operational Technology sits much closer to the physical world. It supports control systems, maintenance operations, safety-relevant procedures, industrial communications, incident response, and engineering decision-making under time pressure. When something goes wrong in OT, the outcome is not always a corrupted database or an exposed secret. It can be downtime, equipment stress, loss of process integrity, off-spec production, environmental impact, or, in the worst cases, harm to people.

If an LLM is embedded in a plant environment, even in a supposedly “advisory” role, its outputs can still shape operational reality, which changes how STI should be evaluated. It may influence how alarms are interpreted, which maintenance task is prioritized, which troubleshooting path is followed, or how a security incident is classified. In other words, the model does not need direct write access to a PLC (Programmable Logic Controller) to become operationally dangerous. It only needs to become trusted enough to steer decisions.

A lot of current industrial AI adoption is happening exactly in these gray zones: not fully autonomous control, but not harmless office productivity either.

Where LLMs Are Already Being Positioned in OT

One reason STI deserves OT-specific treatment is that the literature is already moving LLMs into industrial use cases that carry operational weight.

A 2025 paper on autonomous industrial control using an agentic framework with large language models proposes an architecture made up of operator, validator, and reprompter agents for handling control tasks in real time. The authors explicitly describe a path toward more autonomous industrial decision-making and validate the concept using a temperature-control case study on embedded hardware.

A separate 2025 review on LLM-based agents for predictive maintenance goes even further in terms of architectural realism. It describes agents that can use tools, interact with databases and external systems, draft work orders, analyze root causes, assist with planning, and in extended configurations even affect operating parameters. Just as importantly, the paper is candid about the risks: opacity, authority creep, excessive delegation, and the need for formal capability policies, remote kill switches, drift monitoring, approval gates, and observation-only fallback modes.

Then in 2026, research on LLMs for the protection of Industrial IoT (IIoT) systems in critical infrastructure argued that LLMs can improve incident interpretation and contextual analysis across IT, DMZ (the network segment separating IT and OT), and OT segments, while also emphasizing that industrial environments have strict reliability and business continuity requirements and that LLMs should support decision-making rather than replace established mechanisms.

Taken together, these papers describe something very important: LLMs in OT are no longer just speculative. They are increasingly being placed in roles that interpret, prioritize, recommend, correlate, or prepare action, which is exactly the kind of environment where STI becomes operationally relevant.

What STI Looks Like in an OT Setting

In an OT environment, STI is unlikely to look like a cinematic “AI takes over the plant” event. The more realistic risk is quieter and, in some ways, more dangerous: attacker-controlled content subtly contaminates the model's context, the model produces a plausible but manipulated output, and that output feeds into a trusted operational workflow.

That could happen through direct interaction, but the more interesting OT cases are indirect.

Industrial environments are full of semi-trusted text sources that were never designed with LLM threat models in mind:

  • maintenance tickets
  • shift handover notes
  • alarm comments
  • CMMS (Computerized Maintenance Management System) work-order text
  • engineering knowledge bases
  • vendor advisories
  • support transcripts
  • process incident summaries
  • historian annotations
  • asset descriptions
  • scanned procedures and manuals

Once an LLM is used to interpret or summarize those sources, they all become potential prompt carriers.

The danger is not just that a document might contain “ignore previous instructions.” The danger is that the LLM pipeline may serialize and interpret mixed-trust content in a context where structural markers, role boundaries, or tool-oriented syntax can alter how the system behaves. That is where STI becomes more than a chatbot problem.

OT Example 1: Predictive Maintenance and CMMS Workflows

This is probably one of the clearest industrial examples because it is both realistic and already reflected in the literature.

The predictive-maintenance agent review by Di Maggio describes LLM-based agents that can support diagnosis, reasoning, work-order preparation, spare-parts decisions, and intervention planning. The paper explicitly discusses AI agents that can pre-fill CMMS records, propose maintenance plans, and coordinate multiple sources of information such as anomaly signals, technician availability, spare parts, and production windows.

Now map STI onto that architecture.

Imagine a maintenance copilot that pulls together:

  • sensor anomalies
  • recent failure history
  • technician notes
  • OEM (original equipment manufacturer) guidance
  • free-text maintenance comments

If attacker-controlled content is introduced into one of those channels, say a poisoned work-order note, contractor entry, or imported vendor bulletin, and that content survives into the prompt-building layer, the resulting LLM output may be shaped in ways that are hard to catch quickly.

It may:

  • justify the wrong root cause
  • over-prioritize or under-prioritize a maintenance action
  • create misleading work-order drafts
  • normalize an unsafe troubleshooting step
  • flood the CMMS with noisy but plausible recommendations

The key point is that the LLM does not have to issue a dangerous command directly. It only has to distort the maintenance decision pipeline enough that humans or downstream systems take the wrong next step. Maintenance backlog, equipment wear, and process interruption are not abstract cyber outcomes; they are the OT-specific version of this risk.

OT Example 2: Alarm Triage and Incident Interpretation

This is another area where LLMs are likely to be adopted because the pain point is obvious: too many events, too much context, and not enough time.

The 2026 IIoT paper argues that LLMs can help interpret incidents and correlate heterogeneous data across IT, DMZ, and OT layers in critical infrastructure environments. That makes sense operationally. Security and operations teams already struggle with alert fatigue, fragmented context, and inconsistent labeling across environments.

But the same strength creates a new weakness.

If an LLM-based incident assistant consumes free-text alerts, analyst notes, ICS (industrial control system) metadata, vendor intelligence, or prior case summaries, then attacker-controlled text can shape what the model “understands” about the event. In an STI scenario, that shaping may be structural rather than purely semantic.

In practice, that could mean the model:

  • downplays an intrusion path in the OT segment
  • elevates a benign explanation over a malicious one
  • misclassifies the likely impact
  • presents a manipulated prioritization summary to defenders

That is especially dangerous in industrial environments because incident classification drives escalation. If the assistant gets the framing wrong early, the human team may spend the first critical minutes or hours following the wrong branch of the tree.

This is one reason “LLMs as context engines” in OT deserve more scrutiny than they are getting right now.

OT Example 3: Operator Decision Support and Engineering Search

A lot of near-term industrial AI adoption will likely happen here because it feels safer than autonomous control. Organizations are much more comfortable saying “the model helps operators find procedures” than “the model controls the process.”

That distinction is real, but it should not become false comfort.

If an engineering assistant is used to retrieve procedures, summarize causes, compare incidents, or suggest next checks during abnormal operations, then it becomes part of the operator's cognitive environment. Under pressure, people do not treat a fast, confident, context-rich answer as “just text.” They treat it as guidance.

That matters because OT is full of scenarios where the wrong recommendation is still plausible enough to be followed:

  • restart versus isolate
  • inspect versus continue running
  • derate versus maintain load
  • local reset versus full lockout
  • planned intervention versus immediate escalation

An STI-influenced assistant in this context may not need to generate something obviously malicious. It only needs to create a slight but believable shift in interpretation. In OT, small shifts in interpretation can become large operational consequences.

This is also why the human factors angle matters. Industrial personnel often work under urgency, ambiguity, fatigue, and incomplete visibility. A manipulated assistant can quietly exploit all of those.

OT Example 4: Agentic Industrial Control

This is the hardest category, but it is also the one we cannot avoid talking about.

The autonomous industrial control paper by Vyas and Mercangöz is careful and research-oriented, but it still represents a broader trend: the idea that LLM-based agents may be used to adapt control behavior, recover from disturbances, and coordinate decisions in real time.

Even if these systems remain heavily validated, STI should be treated as a design concern from the beginning.

Why? Because multi-agent control architectures amplify context contamination. If one agent consumes poisoned context and emits a plausible recommendation, another agent may validate it based on the same contaminated context, and a third may package it for execution or operator review. At that point, the injection is no longer a single malformed answer. It becomes part of a distributed reasoning chain.

In security terms, that is ugly.

In OT terms, it is worse, because the ultimate question is not whether the system was tricked, but whether the plant behavior changed because of it.

Why OT Defenders Should Take This Seriously Now

The concern here is not that there are already dozens of public STI incidents in industrial plants. There are not. As of April 23, 2026, we are not aware of a peer-reviewed public case study showing a confirmed STI compromise of a live OT deployment.

What is concerning is the convergence.

We already have:

  • published research showing that special-token-based attacks can materially affect LLM behavior
  • broader evidence that prompt injection is difficult to reliably mitigate across models and tasks
  • public guidance that LLMs do not inherently separate instructions from data
  • industrial research placing LLMs into workflows involving planning, interpretation, validation, and action support

That is enough to justify concern before the first well-documented industrial incident lands in public view.

Security people usually regret waiting for a body count before treating a design pattern as dangerous.

What Good OT Practice Should Look Like

If organizations want LLMs in OT, they should design around the assumption that prompt injection, including STI-style attacks, will remain a residual risk.

That means:

  • keeping strict separation between trusted instructions and retrieved operational content
  • limiting every model-connected tool to minimal privileges
  • forcing deterministic checks before any high-impact action
  • requiring human approval for maintenance, safety, or control-relevant operations
  • preserving existing interlocks, management-of-change, and safety processes
  • logging provenance for every document or note that influences a model output
  • treating RAG (retrieval-augmented generation) sources in industrial environments as untrusted by default

That approach lines up much better with OT culture anyway, where standards like ISA/IEC 62443 already frame industrial cybersecurity as more than confidentiality: it is about system integrity, reliability, continuity, and safety across both IT and operational domains.

LLM deployments should be held to the same standard.

Closing

That is the real story.

Special Token Injection is technically interesting, but what matters more is what it exposes: a fundamental trust problem in LLM-integrated systems.

In operational technology, the danger isn't simply that a model can be manipulated. It's that the model gets embedded in exactly the wrong place: close enough to operations to shape real-world decisions, but abstract enough that teams underestimate what that means.

This is why Special Token Injection shouldn't be dismissed as a niche AI red-team curiosity. It's an early warning for industrial defenders.

The model doesn't need to control anything directly to become the problem. It only needs to become the voice that people, workflows, or adjacent systems start trusting without friction.

In OT environments, the most dangerous AI failures won't announce themselves as breaches or compromises. They'll look like normal operational judgment, just nudged far enough in the wrong direction.

References