VIPRATECH LABS

Security Review for OT/IT AI Assistants

Adversarial testing and architecture review for AI assistants that read historian data, manuals and work orders, covering prompt injection, unsafe advice, data leakage and tool permissions.

Who it is for

  • CISO or Head of OT Security
  • Head of Digital and Industry 4.0
  • OT/IT Architect
  • AI Product Owner

The problem

Utilities, mines and plants are piloting AI assistants that summarise alarms, answer questions from OEM manuals, draft work orders and query historian data. These assistants sit close to the IT/OT boundary and take instructions from the text they read, which creates risks a conventional VAPT does not cover.

Assistants straddle the IT/OT boundary

A copilot that reads historian tags and writes to the CMMS can become a path across zones the network design was meant to keep apart.

Instructions hidden in documents

Indirect prompt injection through a vendor manual, work order or email can change what the assistant says or does.

Unsafe procedural answers

An assistant that can be talked into skipping isolation steps or bypassing an interlock is a safety issue, not just a security bug.

Tool permissions grow quietly

Read-only pilots acquire write access to tickets, notifications or scripts as features are added, without fresh review.

What we build

We run a structured security review of the assistant before it reaches plant users, and again after significant changes. We map its data flows, tools and identities against your OT zones, then build test playbooks for your setting: direct and indirect prompt injection, jailbreaks aimed at unsafe procedures, leakage of network diagrams, credentials and personal data, and misuse of every tool the assistant can call. Our multi-agent test framework runs these playbooks against a staging instance, never live control systems. Security engineers validate each finding, record reproduction steps and evidence, propose fixes and retest once you have remediated.

  • Architecture and data-flow review against your IT/OT zones and conduits
  • Direct and indirect prompt injection tests through manuals, work orders, emails and tickets
  • Unsafe-procedure tests such as skipping isolation, bypassing interlocks or silencing alarms
  • Tool and permission review for least privilege and read-only access to OT data
  • Leakage tests for network diagrams, credentials, plant drawings and personal data
  • Evidence pack mapped to OWASP Top 10 for LLM Applications, NIST AI RMF and IEC 62443 concepts

How it works

  1. 01Agree scope and rulesWe agree the assistant, environment, test windows and rules of engagement with your OT and IT security teams.
  2. 02Map data flows and toolsWe document what the assistant reads, which tools it can call, which identities it uses and where it crosses zone boundaries.
  3. 03Run test campaignsThe test framework runs adversarial playbooks against the staging instance and records every prompt, response and tool call.
  4. 04Validate findingsA security engineer reproduces each candidate finding and assesses its real impact.
  5. 05Report with fixesFindings are reported with severity, evidence and specific remediation such as permission changes, input filtering or prompt and retrieval fixes.
  6. 06RetestAfter remediation we rerun the relevant playbooks and close findings with evidence.
Security Review for OT/IT AI Assistants: workflow diagram
Open full size

Architecture

  1. Scoping
    • Asset and data-flow inventory
    • Threat model for the assistant
    • Rules of engagement
  2. Test framework
    • Attack playbook library
    • Multi-agent test orchestrator
    • Staging connectors with synthetic plant data
  3. Evaluation
    • Response and policy classifiers
    • Tool-call monitor
    • Human validation by security engineers
  4. Reporting
    • Findings register
    • Evidence pack with framework mapping
    • Retest tracker
Security Review for OT/IT AI Assistants: architecture diagram
Open full size

Inputs and outputs

Inputs

  • Architecture and network zone diagrams
  • System prompts, retrieval sources and tool definitions
  • Access to a staging instance with test identities
  • Sample documents such as manuals and work orders
  • Existing OT security policies and user roles

Outputs

  • Findings register with severity and reproduction steps
  • Prompt, response and tool-call evidence logs
  • Remediation recommendations for each finding
  • Mapping to OWASP Top 10 for LLM Applications, NIST AI RMF and IEC 62443 concepts
  • Retest report

Where people stay in control

Security engineers validate every finding before it is reported, and testing stays within the agreed rules of engagement and staging scope. Your team decides which risks to fix, accept or transfer.

Integrations

  • LLM platforms such as Azure OpenAI, AWS Bedrock or self-hosted models
  • Staging copies of historian and CMMS connectors
  • SIEM for log review
  • Jira or ServiceNow for findings tracking
  • Identity provider for test accounts

Guardrails

  • No testing against live control systems; staging or replica environments only
  • Signed rules of engagement before any test
  • Synthetic plant data in test documents
  • No destructive payloads or persistence
  • Findings shared only through agreed secure channels

Compliance notes

  • Findings can be mapped to IEC 62443 concepts, OWASP Top 10 for LLM Applications and NIST AI RMF to support your OT security programme.
  • Helps power-sector entities evidence risk assessment of new digital systems under CEA cyber security guidelines.

A typical pilot

Duration: 3 weeks

One assistant, such as a maintenance copilot that reads manuals and drafts work orders, tested in staging with its current tools and data sources.

Deliverables

  1. 01Data-flow map and threat model
  2. 02Test campaign results with evidence
  3. 03Findings report with remediation guidance
  4. 04Retest of fixed findings
  5. 05Recommendations for ongoing regression testing

What we measure

Threat coverage
Categories from the threat model exercised by at least one playbook.
Validated findings by severity
Count of reproducible findings at each severity after engineer validation.
Tool-policy violations
Tool calls observed outside the intended permission set during tests.
Fix verification
Share of findings closed on retest.

Built on related work

Agentic AI penetration-testing platform

NZ penetration-testing-as-a-service company (anonymised)

Supervisor-based multi-agent platform for endpoint discovery, attack-surface mapping, OWASP Top 10 and business-logic testing, live vulnerability validation and exploit-chain evidence.

FAQs

01Will your testing touch our live SCADA or DCS?

No. We test a staging or replica instance of the assistant with synthetic data, under signed rules of engagement. If the assistant has any path to live OT, that path is itself a finding we report.

02How is this different from our annual VAPT?

A VAPT tests networks and applications for known vulnerability classes. This review tests how the AI behaves: whether text it reads can change its instructions, whether it gives unsafe procedural advice and whether its tools can be misused. The two complement each other.

03What do you need from us to start?

Architecture diagrams, the assistant's prompts and tool definitions, a staging instance with test accounts and a contact in OT security. Sample documents help us build realistic injection tests.

04Can the tests be repeated after changes?

Yes. Playbooks are kept as a regression suite, so the same tests run after model, prompt or tool changes, and results are compared with the previous round.

Related use cases

Akhilesh Mittal

Founded by Akhilesh Mittal. 8 years building a security platform for a New Zealand company. IIT ISM Dhanbad and IMT Ghaziabad. Builds production agentic AI.

Start with one site, one camera cluster or one call queue

Book a discovery call to choose a narrow pilot on your own footage, reports or call recordings. We agree the measures with your team before any build starts.