Threats

Prompt injection: how AI assistants in dashboards and logs become an OT risk

AI assistants are being added to dashboards, historians and ticketing tools. If they read text an attacker can influence, they can be steered. Here is the risk and how to contain it.

Charts of performance analytics displayed on a laptop screen
Photo: Luke Chesser on Unsplash

Prompt injection is an attack in which instructions hidden in text are read by an AI model and followed as if they came from the user. It is ranked first on the OWASP list of risks for LLM applications. It matters for operational technology because AI assistants are being added to the tools OT teams already use, such as dashboards, historians, log viewers and ticketing systems, and those tools are full of text that outsiders can influence.

How indirect prompt injection works

A direct attack is typed into a chat box. An indirect attack hides the instruction in data the assistant is later asked to read: a log line, a web page, a document, a ticket, an email, a device name. When an operator asks the assistant to summarise it, the model cannot reliably tell the data from the instructions, so it may act on both.

A recent example: GrafanaGhost

In April 2026 Noma Security disclosed GrafanaGhost, a flaw in the AI features of Grafana, a widely used dashboard platform that many industrial and energy teams use for telemetry. According to CyberScoop's report, researchers chained three weaknesses: a URL check that treated an attacker's address as safe, a guardrail that a particular phrase talked the model around, and an image request that carried data out to an attacker's server.

Grafana Labs fixed the issues. It disputed the "zero-click" description, saying exploitation needed significant user interaction, and stated it had seen no evidence of exploitation in the wild and no data leaked from Grafana Cloud. Both accounts are worth holding at once: the weakness was real and patched, and the severity is contested. The lesson is the pattern, not this one product.

Laptop showing engineering software on a workbench beside industrial equipment
Engineering and monitoring tools hold sensitive context, so anything that can read it needs the same scrutiny as a new network connection. Photo: ThisisEngineering on Unsplash

Why this matters in OT

  • OT tools hold sensitive context. Dashboards and historians show process values, asset names, network layouts and alarms. Exfiltrating that is reconnaissance for a later attack.
  • Untrusted text is everywhere. Alarm descriptions, maintenance notes, vendor documents, remote-session logs and tag names can be written by people or systems outside your trust boundary.
  • Assistants may be given actions. The risk rises sharply when an assistant can send messages, create tickets or call other systems, and becomes serious if any path leads towards control functions.
  • Convenience grows faster than review. Features are switched on by default or by an enthusiastic team before security has assessed them.

The December 2025 joint guidance from CISA, Australia's ASD and partners on integrating AI into OT, which we cover in Securing AI in OT, makes the same point: keep humans accountable and be careful about what AI can touch. The EU AI Act adds governance duties for some AI uses.

Practical controls

  1. Inventory AI features. List every assistant, copilot or plug-in in OT and DMZ tools, who enabled it, and what data it can read.
  2. Make AI read-only by default. No write access to control systems, and no ability to change configurations. Require human approval for any action.
  3. Treat everything it reads as untrusted. Do not point assistants at free text that outsiders can write to unless you accept the risk.
  4. Block the exfiltration route. Restrict outbound connections from the tools that host the assistant, and disable features that load external content such as images or links.
  5. Separate zones. Keep AI-enabled tools in the DMZ or IT side, not inside the control zone, and allow only documented conduits.
  6. Log and review. Record prompts, tool calls and outputs so that unusual behaviour can be investigated.
  7. Assess before enabling. Treat an AI feature like any new connection into OT: define scope, test it, and record the decision.

How OTVista helps

OTVista keeps the evidence for those decisions together. Zones & Conduits shows which tools sit where and what they can reach, Identity & Access limits who and what holds permissions, and Governance and Evidence & Audit record approvals and review dates. A practitioner can review AI exposure as part of an OT security architecture review or an OT cybersecurity assessment. The free Quick Check is a quick starting point.

Related: AI in OT security: what it can and cannot do.

Sources: Noma Security disclosure of GrafanaGhost as reported by CyberScoop (7 April 2026), including Grafana Labs' response; OWASP Top 10 for LLM Applications (LLM01 Prompt Injection); CISA, ASD's ACSC and partners, "Principles for the Secure Integration of Artificial Intelligence in Operational Technology" (December 2025); Regulation (EU) 2024/1689 (AI Act). This article is general information, not legal advice.

Topics: prompt injection, prompt injection attack, AI assistant security, GrafanaGhost, AI in OT security, OT data exfiltration, indirect prompt injection

Frequently asked questions

What is prompt injection in simple terms?

It is when hidden instructions inside text, such as a log entry or document, are read by an AI assistant and followed as if the user had asked for them. Models cannot reliably separate data from instructions.

Can prompt injection affect industrial control systems?

Directly, only if an assistant is connected to something that can change the process, which it should not be. The more realistic risk is leaking sensitive operational data or misleading the people who rely on the assistant's summaries.

Was GrafanaGhost exploited in real attacks?

Grafana Labs said it found no evidence of exploitation in the wild, patched the issues and disputed the zero-click description. It is a useful illustration of the attack pattern.

Should we ban AI assistants in OT environments?

Not necessarily. Keep them read-only, outside the control zone, limited in what they can read and send, and approved through a recorded assessment.

See OTVista in action

Get early access to the OTVista tool or talk to us about your OT security priorities.

Get early access