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.
- Capability:
- AI Security & Compliance
- Industry:
- Energy, Mining & Utilities
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
- 01Agree scope and rulesWe agree the assistant, environment, test windows and rules of engagement with your OT and IT security teams.
- 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.
- 03Run test campaignsThe test framework runs adversarial playbooks against the staging instance and records every prompt, response and tool call.
- 04Validate findingsA security engineer reproduces each candidate finding and assesses its real impact.
- 05Report with fixesFindings are reported with severity, evidence and specific remediation such as permission changes, input filtering or prompt and retrieval fixes.
- 06RetestAfter remediation we rerun the relevant playbooks and close findings with evidence.
Architecture
- Scoping
- Asset and data-flow inventory
- Threat model for the assistant
- Rules of engagement
- Test framework
- Attack playbook library
- Multi-agent test orchestrator
- Staging connectors with synthetic plant data
- Evaluation
- Response and policy classifiers
- Tool-call monitor
- Human validation by security engineers
- Reporting
- Findings register
- Evidence pack with framework mapping
- Retest tracker
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
- 01Data-flow map and threat model
- 02Test campaign results with evidence
- 03Findings report with remediation guidance
- 04Retest of fixed findings
- 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
- Energy, Mining & Utilities
Technical Report Search Assistant
A search assistant over geological, engineering and incident reports that answers engineers' questions with page-level citations and respects existing document permissions.
- Manufacturing
Security Review for Plant and Enterprise AI Copilots
Test copilots that touch SAP, CMMS, drawings and costings for prompt injection, data leakage and unsafe tool access before they reach plant users, with validated findings and fixes.
- Fintech & Payments
AI Agent Permission and Tool-Use Security Review
Find out what your AI agents can actually do: which tools, credentials and money-moving actions they reach, where approvals sit, and whether injected text can make them misuse tools.
- SaaS & AI Product Companies
Continuous AI Security Regression in CI
Run versioned prompt-injection, jailbreak and data-leakage suites in CI on every prompt, model, tool or index change, and block releases that regress past agreed severity thresholds.

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.